[Python-Dev] Extension to ConfigParser (original) (raw)

Ian Bicking ianb at colorstudy.com
Wed Feb 1 05:32:20 CET 2006

Sorry, I didn't follow up here like I should have, and I haven't followed the rest of this conversation, so apologies if I am being redundant...

Fuzzyman wrote:

While ConfigParser is okay for simple configuration, it is (IMHO) not a very good basis for anyone who wants to build better systems, like config files that can be changed programmatically, or error messages that point to file and line numbers. Those aren't necessarily features we need to expose in the standard library, but it'd be nice if you could implement that kind of feature without having to ignore the standard library entirely.

Can you elaborate on what kinds of programattic changes you envisage ? I'm just wondering if there are classes of usage not covered by ConfigObj. Of course you can pretty much do anything to a ConfigObj instance programattically, but even so...

ConfigObj does fine, my criticism was simply of ConfigParser in this case. Just yesterday I was doing (with ConfigParser):

conf.save('app:main', '## Uncomment this next line to enable authentication:\n#filter-with', 'openid')

This is clearly lame ;)

That said, I'm not particularly enthused about a highly featureful config file format in the standard library, even if I would like a much more robust implementation.

I don't see how you can easily separate the format from the parser - unless you just leave raw values. (As I said in the other email, I don't think I fully understand you.) If accessing raw values suits your purposes, why not subclass ConfigParser and do magic in the get* methods ?

I guess I haven't really looked closely at the implementation of ConfigParser, so I don't know how serious the subclassing would have to be. But, for example, if you wanted to do nested sections this is not infeasible with the current syntax, you just have to overload the meaning of the section names. E.g., [foo.bar] (a section named "foo.bar") could mean that this is a subsection of "foo". Or, if the parser allows you to see the order of sections, you could use [[bar]] (a section named "[bar]") to imply a subsection, not unlike what you have already, except without the indentation.

I think there's lots of other kinds of things you can do with the INI syntax as-is, but providing a different interface to it. If you allow an easy-to-reuse parser, you can even check that syntax at read time. (Or if you keep enough information, check the syntax later and still be able to signal errors with filenames and line numbers)

An example of a parser that doesn't imply much of anything about the object being produced is one that I wrote here: http://svn.colorstudy.com/INITools/trunk/initools/iniparser.py

On top of that I was able to build some other fancy things without much problem (which ended up being too fancy, but that's a different issue ;)

From my light reading on ConfigObj, it looks like it satisfies my personal goals (though I haven't used it), but maybe has too many features, like nested sections. And it seems like maybe the API can be

I personally think nested sections are very useful and would be sad to not see them included. Grouping additional configuration options as a sub-section can be very handy.

Using .'s in names can also do grouping, or section naming conventions.

-- Ian Bicking | ianb at colorstudy.com | http://blog.ianbicking.org

More information about the Python-Dev mailing list