[Python-Dev] Extension to ConfigParser

[Fuzzyman]

Ian Bicking wrote:
> Guido van Rossum wrote:
>   
>>> I don't think enhancing ConfigParser significantly is a good way
>>> forward.  Because of ConfigParser's problems people have made all sorts
>>> of workarounds, and so I don't think there's any public interface that
>>> we can maintain while changing the internals without breaking lots of
>>> code.  In practice, everything is a public interface.  So I think the
>>> implementation as it stands should stay in place, and if anything it
>>> should be deprecated instead of being enhanced in-place.
>>>       
>> Somehow that's not my experience. What's so bad about ConfigParser?
>> What would break if we rewrote the save functionality to produce a
>> predictable order?
>>     
>
> That's a fairly minor improvement, and I can't see how that would break 
> anything.  But Michael (aka Fuzzyman -- sorry, I just can't refer to you 
> as Fuzzyman without feeling absurd ;) 
Don't worry, absurdity is a common reaction I inspire in people.
Actually Fuzzyman is more of a description than a nickname. I understand
that I may not be the only one worthy of such a title of course. ;-)

> was proposing ConfigObj 
> specifically (http://www.voidspace.org.uk/python/configobj.html).  I 
> assume the internals of ConfigObj bear no particular resemblence to 
> ConfigParser, even if ConfigObj can parse the same syntax (plus some, 
> and with different failure cases) and provide the same public API.
>
> 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...

> 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 ?

>  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.

> reduced in size with a little high-level refactoring -- APIs generally 
> grow over time so as to preserve backward compatibility, but I think if 
> it was introduced into the standard library that might be an opportunity 
> to trim the API back again before it enters the long-term API freeze 
> that the standard library demands.
Hmmm.... possibly. :-)

walk, decode and encode are the obvious extraneous methods. walk can be
re-implemented as a recursive function and encode/decode will be
unnecessary when unicode support is complete.

Additional complexity comes from retaining all comments and supporting
validation. I think retaining comments is worthwhile, because it allows
a program to modify a config file (e.g. from a GUI) without losing user
comments in a handwritten config file.

The validation support has several levels to it - but it can be
completely ignored with no complexity for the user. Some validation
support is integrated into instantiation, but this could *probably* be
broken out into a subclass.

Anyway, ho hum - possibly. All for future hypothetical discussion I guess...

All the best,

Fuzzyman
http://www.voidspace.org.uk/python/configobj.html