ConfigParser shootout, preliminary entry
dw at botanicus.net
Sat Oct 23 13:23:40 CEST 2004
Skip Montanaro wrote:
> * Both attribute-style and dictionary-style access supported
Can someone please enlighten me as to why this is a good idea? The abuse
of __getitem__ or __getattr__ (IMHO) should only occur inside
transparent object proxies and suchlike -- I see no relation between
(key, value) mapping and attributes.
I also have trouble with the __getitem__ idea, although I can see at
least that this might make sense if you consider your configuration some
sort of dictionary or array. In any case, I quote from 'import this':
'There should be one-- and preferably only one --obvious way to do it.'
I see two ways to do it here. :)
> * Typeless - everything's a string. Python has plenty of ways to
> convert strings to other types of objects.
Finally, another believer. :)
> I wrote it more as an exercise and to satisfy myself that to deal with more
> general config structures than Windows INI files supports you don't have to
> fall into the XML tarpit. I suspect it's not more featureful than Michael
> Chermside's example implementation though it's somewhat shorter.
IMHO you are blurring the lines between complex data storage and simple
INI files. Microsoft's history here was to move to the Windows registry
- a concept that could be easily represented in the modern age as an XML
Again, I'll raise the point that this work is being done under the false
banner of 'ConfigParser' -- this is the only reason I have come out of
idleness, it has nothing to do with ConfigParser. It is a new concept
entirely. Could we reserve the name 'ConfigParser' for configuration
parsers that at least in function or form resemble the original, like
any sane developers should.
If you agree with me on the above, then again I think you should first
hammer out exactly what you *need* your new configuration system to
accomplish, and then perhaps agree on an unambiguous name for it.
In the meantime, AFAICS the only implementation that deserves the name
'ConfigParser' so far is my own -- and I only wrote it to prove this point.
As per a recent popularly read weblog entry written by A.M.K., the
standard library is aged and disorganised. The thought of a replacement
ConfigParser module that embodies an entirely different configuration
storage concept doesn't sound like it is going to help this situation much.
I think the way forward here is to define the goals of a new
configuration framework that supports sillyness like magical attribute
access and multiple backends (with a first backend being an XML DB or
pickle or similar), then additional 'mix in' features such as schemas,
then after we have a featurelist, open the shootout again.
Perhaps a PEP or SIG could be opened on the topic, and development could
commence in a sane fashion.
In the meantime, all I'm seeing is different people's ideas of cool
behaviour and their own ideas on how they'd like to see the standard
configuration system work.
PS: Sorry if this seems bitchy in any way, it's just I am genuinely
concerned for the purity of my popularly used darling stdlib
ConfigParser module. :)
More information about the Python-list