[Python-Dev] Extension to ConfigParser

[Ian Bicking]

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