[Python-Dev] ConfigParser patches

[Brett C.]

Guido van Rossum wrote:
[SNIP]
>>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.
> 

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" 
"http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
	<key>Section</key>
	<dict>
		<key>key</key>
		<string>value</string>
		<key>key2</key>
		<string>value2</string>
	</dict>
</dict>
</plist>

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

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.

-Brett