[Python-Dev] ConfigParser patches

[Guido van Rossum]

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