[Web-SIG] WSGI adoption
py-web-sig at xhaus.com
Mon Nov 29 20:46:02 CET 2004
[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
> 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.
Which includes the following quotes
>>> Ideally, the docs should discourage further non-string uses and
>>> advise that ConfigParser will be string only for Py3.0.
>> 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
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
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.
More information about the Web-SIG