[Python-Dev] ConfigParser patches

[Guido van Rossum]

> >  > Ideally, the docs should discourage further non-string uses and advise
> >  > that ConfigParser will be string only for Py3.0.
> >
> > Yikes!  Can't we just toss it for Py3K?  This module just hasn't held up, and
> > exposes a really poor model even for .ini-style configuration files.

Hear hear.

> Ditto from me.  Personally I would want something that used XML (like property
> lists on OS X), but I realize people still want a config file style that is
> easy to modify in a text editor, so I don't see the .ini style going away.  But
> we could stand to come up with a uniform interface that both an XML and .ini
> config file parsers could use for consistency and thus support both styles.

Well, for me personally, .ini style config files still win over XML
every day. And I now have significant experience with both here at
ESI.

What sucks (relatively) is the specific way that ConfigParser provides
access to .ini files; I always end up writing a wrapping layer around
it.

> Wasn't there talk for a while of doing an shootout of config file packages like
> we did for optparse?

There are two different axes here: the config file format and the API
for accessing it.

I'm not sure that attempting to provide a single API for both XML and
.ini files will work; the API should reflect the structure of the file
(to some extent) and that's just too different. But I may be wrong; I
do see some similarities:

What I have come to like, both for dealing with XML and with .ini
files, is something that lets you map the configuration values (or
whatever it is that you're parsing, really) to Python attributes. This
is really some kind of simplified DTD support, and there are different
ways to go about it; but the net result is that you end up writing
e.g. options.client.max_retries (which is an int with a default value)
rather than options.getint("client", "max-retries").

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)