ConfigParser shootout, preliminary entry

David Wilson dw at
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[2] 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 mailing list