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.
This reveals IMO a big mistake in thinking about configuration files. The most important user of a config file is not the programmer who has to get data out of it; the most important user is the user who has to edit the config file. The outrageous verbosity of XML makes the above example a complete usability liability. Now, if you're talking about config files that represent options that the user edits in a convenient application-specific options dialog, that's a different story; I think XML is well-suited for that; but I'm talking about the classic configuration file pattern where you use your favorite flat-file text editor to edit the options file. In that situation, using XML is insane.
Is this worth working on now or wait until Py3k?
I see no advantage in waiting until Py3K; this is not a language issue and there is no problem with having several library modules (as long as it's clear which one is deprecated). -- --Guido van Rossum (home page: http://www.python.org/~guido/)