[Python-Dev] Extension to ConfigParser

[Ian Bicking]

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

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.

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

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