[Python-Dev] Extension to ConfigParser

Fuzzyman fuzzyman at voidspace.org.uk
Mon Jan 30 21:19:49 CET 2006


Guido van Rossum wrote:
> On 1/30/06, Ian Bicking <ianb at colorstudy.com> 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?
>   
Well, what I'm suggesting is not merely enhancing ConfigParser in place
- but replacing it with the ConfigObj and a compatibility layer to
support legacy code.

As I mentioned, it would require *some* changes to the parser
(ConfigObj) to be fully compatible with the existing syntax, but that is
well achievable. The aim would be that no existing code breaks, and few
(if any) config files break. I could flesh this out in a PEP if it was
likely that it would be accepted.

Issues with ConfigParser that ConfigObj *immediately* fixes :

* Simpler API - uses dictionary syntax/methods for
adding/deleting/accessing keys and sections (Each section - including
the ConfigObj itself - is a dictionary subclass with all methods available)
* Nested sub-sections to any depth.
* Fully integrated (extensible) validation schema system, with type
conversion. No complexity overhead for not using it.
* List values parsed by default (handling quotes sanely)
* Retains order of keys/section for iteration and writing out config file.
* Retains *all* comments and allows inline comments

The next enhancement will add full unicode support, which for a text
based format really makes sense and I should have implemented it earlier.

Additionally ConfigObj allows values in the root section - meaning that
for simple config files you aren't *forced* to have an arbitrary 'section'.

All the best,

Fuzzyman
http://www.voidspace.org.uk/python/configobj.html
> --
> --Guido van Rossum (home page: http://www.python.org/~guido/)
> _______________________________________________
> 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
>
>   



More information about the Python-Dev mailing list