[Web-SIG] WSGI adoption

[Phillip J. Eby]

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.