[Python-Dev] ConfigParser patches
bac at OCF.Berkeley.EDU
Sat Oct 2 00:30:44 CEST 2004
Guido van Rossum wrote:
>>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
OK. Do realize that plists are basically .ini style just expressed in XML::
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN"
I am not thinking of anything fancy or beyond something like this; .ini files
expressed in XML. Just thinking that XML might be nice since all of those poor
souls who don't use Python have easy access to an XML parser but not
necessarily a .ini file parser.
> What sucks (relatively) is the specific way that ConfigParser provides
> access to .ini files; I always end up writing a wrapping layer around
>>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:
For free-wheeling XML, yes, I would agree, but if we restrict the
DTD/schema/spec to be fairly similar to .ini files then I don't think the
structure of the files will be that drastic. And as long as people use the API
to create/edit/save the files then we can enforce universal rules that makes
sure that the difference is really just in the structure of the output.
> 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").
That is what I am thinking. You have sections and then key/value pairs within
the sections in both the XML and the .ini format. We then just agree on how
case-sensitivity, naming, etc. works within the file formats and then provide a
common-place interface much like the one you lay out above.
Is this worth working on now or wait until Py3k? It probably seems like I am
playing the PEP drum (not a fan of the harp =) a lot lately in regards to
stuff that is going to not be an issue until Py3k, but the longer we have to
work on something the better chance we have of having something that everyone
likes. Plus for things like modules we can provide it for people now as an
external module for experimentation and thus be a little willy-nilly with the
API initially until we have it nailed and either integrate into the stdlib
beofre Py3k or just wait until then.
More information about the Python-Dev