[Web-SIG] WSGI adoption
Phillip J. Eby
pje at telecommunity.com
Mon Nov 29 22:29:41 CET 2004
At 07:46 PM 11/29/04 +0000, Alan Kennedy wrote:
>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.
My understanding is that the problems are with the API exposed by
ConfigParser, not the format or even its implementation per se. You will
notice that Guido says he "always end[s] up writing a wrapping layer around
it", not that he doesn't use it!
>3. Even if we did use ConfigParser, it still doesn't solve the lack of
>encoding support.
True, but entirely manageable for any 8-bit encoding that doesn't require
escaping for the characters (such as #, ; , [, =, ], :, and whitespace)
that ConfigParser uses for syntax. IOW, the various Latin codings and
UTF-8 are all fine.
>4. Other people are having exactly the same problems deciding how best to
>approach configuration.
Actually, they aren't. The ConfigParserShootout has expanded scope
tremendously over the original Python-Dev discussion, which was much more
about API than format. The needs for a WSGI deployment format are much
more straightforward.
The format MUST be:
* Easy for non-programmer users to read, write, and edit (which implies a
variety of more detailed requirements, such as case-insensitivity for
configuration keys, and a lack of excessive quoting or escaping)
* Extensible, such that programs can ignore parts that are not intended for
them
* Able to represent filenames, strings, numbers, and boolean flags.
The format SHOULD be:
* Easy for a GUI or other tool to edit or generate
To me, the .ini syntax's only failing in these requirements so far is that
an encoding would need to be specified for strings.
Whether the ConfigParser library itself should be used or not, I don't
know. Its advantages are:
* It's been in the standard library a long time, meaning it's available on
the platforms of interest for WSGI
* It handles booleans in a user-friendly fashion, at least for
English-speaking users.
* It allows string interpolation for the hackerly types who don't like
repeating themselves
Its disadvantages are:
* Implementation has changed a lot over its history
* Documentation is accused of being "handwavy"
* Format is not rigorously defined
Of course, I would be fine with us rigorously defining a format that met
the requirements.
One other possibility I can see, would be the Java properties file format,
or something similar to it.
More information about the Web-SIG
mailing list