Re: Configuration file
[Top] [All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
On Wed, Jul 24, 2002 at 11:13:25PM -0400, Martijn Pieters wrote:
> I must say that I feel that too much Python syntax in the configuration file
> will confuse non-programmers; one of reasons I am working on the
> config-manager is to make it easier for such users to manage the
> configuration without having to understand every detail of it.
Well, I may disagree with you on this one but I do agree with you on
everything else. I see the Python syntax, especially the lambdas, as a
great asset because it makes OfflineIMAP much more versatile and powerful
than it otherwise would be. Where this sort of syntax is used, I have tried
to copiously document it with lots of examples of common use, so people that
do not know Python should be able to just uncomment and modify the
configuration that applies to them. That's the goal, anyway.
So what I'm saying is: I support ways to make it easier to deal with the
tricky things like lambdas (such as your configurator project, more docs,
etc.) but not removing the eval'd stuff entirely.
I think the "Account " prepending solution whose time may be here. I had
considered that back before version 1.0, but in a Gatesian "640k will be
enough to anybody" sort of move, concluded that there'd never be a need for
any section other than [general] anyway :-)
> You can then add other namespaces for other types of configuration, such as
> UI confiurations; 'UI Blinkenlights' springs to mind. Using a name like that
> also doesn't bind you to a package organisation or implementation. Maybe one
> day there will be a ui.wxPython.Blinkenlights instead?
Yes. So we have to wonder, would ui.wxPython.Blinkenlights,
ui.Tk.Blinkenlights, ui.MacOSX.Blinkenlights want to share the same section
or have different ones? (It's conceivable that they might all be present
simultaneously)
Incidentally, I chose Tkinter for the GUI stuff only because it's most
ubiquitous. Sending Python commands to an embedded Tcl interpreter that in
turn uses the Tk library is not my idea of the right way to do it. I still
don't understand why they didn't just use the Tk C binding, sigh. At least
it's thread-safe these days.
--
John Goerzen <jgoerzen@xxxxxxxxxxxx> GPG: 0x8A1D9A1F www.complete.org
|
|