[Python-Dev] Extension to ConfigParser

[Michael Foord]

Paul Moore wrote:
> On 1/30/06, Guido van Rossum <guido at python.org> wrote:
>   
>> Aha. I am beginning to understand. When people say "ConfigParser is
>> hopeless" they mean ".INI files are hopeless". I happen to disagree.
>> (There's also a meme that says that every aspect of an app should be
>> configurable. I disagree with that too. As Joel Spolski points out in
>> his book on UI design, most configuration options are signs of
>> indecisive developers, and most users never change the defaults.)
>>     
>
> While you're right that a lot of the comments people make about
> ConfigParser are actually about INI files (e.g., no nested sections,
> no "top-level" values), I do find that when I use ConfigParser, I
> often need to write a wrapper around it to make it more usable.
>
> A couple of examples, from a current application:
>
> * No way to merge files or sections. Usually to provide default
> values. I have a suite of applications, all using the same framework.
> I have a hardcoded DEFAULT_CONFIG in the code, overriden by a
> <suite>.ini, overridden again by a <app>.ini. OK, maybe it's
> overengineered, but I do use the various levels, so it's also
> useful... (The defaults parameter to the constructor is misnamed,
> AFAICT, as it's for interpolation defaults, not value defaults).
>
> * A dictionary interface, or even attribute access (where the key
> names are Python identifiers, which is usually the case), is usually
> far cleaner to work with in code. For example, conf.log.level vs
> conf.get('log', 'level'). But that may just be me - it's certainly a
> style issue.
>
> Nothing major, but worth considering.
>
> I agree entirely that once you go beyond INI format, you should have a
> new module. Of course, ConfigParser already allows more than basic INI
> format ("key: value" lines, continuations, and substitution strings)
> but we'll gloss over that... :-)
>   
Well, ConfigObj is listed as an XML alternative at :

    http://www.pault.com/pault/pxml/xmlalternatives.html

For complex configuration situations, many people feel that handcrafting 
XML is not a fun alternative.

One of the driving forces behind ConfigObj was a firm that *used* to 
have their system administrators using ZConfig, but wanted something 
more friendly.

They have configuration files nested a few levels deep configuring 
services, plugins, network details, etc. This is all properly 
'application configuration'. (Not data persistence.)

The file format (and config structure) is easily visible from the files. 
The config files are automatically validated from the schema 
(configspecs) which also facilitate the automatic creation of new sections.

I *personally* think that this is a common use case and the format is a 
natural extension of the 'INI-like' format. I'm happy for it to remain a 
separate module (as indeed ConfigObj will). There are several valid 
complaints about ConfigParser - and it is *possible* (although possibly 
not desirable) to largely solve them all without breaking backwards 
compatibility with ConfigParser.

Is it likely that an *additional* module could be added ? The suggestion 
to narrow the ConfigObj API and not subclass dict (but still use the 
mapping protocol) are interesting, and certainly not out of the 
question. Nested sections however, are a significant part of the reason 
for it's existence.

All the best,

Fuzzyman
http://www.voidspace.org.uk/python/index.shtml

> Paul.
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk
>
>