[Web-SIG] WSGI adoption

[Alan Kennedy]

[Phillip J. Eby]
> ZConfig isn't a bad format overall, but it does have a rather serious 
> problem for the deployment format: it expects to have a fixed schema, 
> which means there's not really a good way to have a file that contains 
> information for one server to use, and another server to ignore, while 
> there's also information for the app that the server ignores and vice 
> versa.
> 
> You can of course hack its schema mechanism to accommodate such a 
> format, but at that point you've also removed all of the validation and 
> processing that it does, so you might as well go back to plain .ini 
> format, which at least has a parser in the standard library.

I did a little reading about ConfigParser. I found the following 
interesting thread from python-dev last month.

http://mail.python.org/pipermail/python-dev/2004-October/049167.html

Which includes the following quotes

"""
[David Goodger]
 >>> Ideally, the docs should discourage further non-string uses and
 >>> advise that ConfigParser will be string only for Py3.0.

[Brett Cannon]
 >> 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.

[Guido van Rossum]
 > Hear hear.

 > What sucks (relatively) is the specific way that ConfigParser
 > provides access to .ini files; I always end up writing a wrapping
 > layer around it.
"""

The outcome of that discussion was a ConfigParser shootout, which you 
can read here

http://www.python.org/moin/ConfigParserShootout

So it seems that

1. There are a number of problems with ConfigParser.
2. These problems are sufficiently bad that GvR has declared he'd be 
happy to consider replacements.
3. Even if we did use ConfigParser, it still doesn't solve the lack of 
encoding support.
4. Other people are having exactly the same problems deciding how best 
to approach configuration.

It is also interesting to note GvR's dislike of XML

"""
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.
"""

http://mail.python.org/pipermail/python-dev/2004-October/049179.html

Regards,

Alan.