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/)