[Web-SIG] WSGI adoption

[Phillip J. Eby]

At 04:15 PM 11/29/04 -0600, Ian Bicking wrote:
>Or, if applied as a wrapper, you could decode all the strings after 
>they've been loaded.  Maybe that's what you were thinking?

Yes, I meant decode-after-load, specifying the encoding as one of the 
configuration variables.


>Extensibility also requires (IMHO) the layering of multiple configuration 
>files**.

Eh?


>>The format SHOULD be:
>>* Easy for a GUI or other tool to edit or generate
>
>ConfigParser does poorly at this; if I was to do this with ConfigParser 
>you'd really end up doing some sort of funny thing where you made a 
>separate parser that would look for the point in the file you want to add 
>a key, then do so, and modify ConfigParser so it kept track of the changes 
>that were made to it; ConfigParser itself doesn't facilitate this at all.

I didn't mean "edit while preserving structure and comments", only "edit 
while preserving semantics".


>>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
>
>Because no one is (or would) propose any alternative other than a 
>plain-Python module, it's not a big deal to distribute it separately. 
>Especially if there are version issues with old versions of Python and 
>ConfigParser.  (I'm not sure if there is, but if we want to enhance 
>ConfigParser even slightly then there will be)

If we do anything other than just say, "Use ConfigParser", then IMO we need 
to spell out the semantics, and create a clean implementation of those 
semantics.


>>* It allows string interpolation for the hackerly types who don't like 
>>repeating themselves
>
>People seem unhappy with this feature.  At least there were several people 
>in the python-dev who felt this way.  The fact that there's a "more sane" 
>version of this (SafeConfigParser) makes it seem like a questionable 
>feature.  It's also useful, so I'm not entirely sure what to make of 
>it.  But then if we go down that path, conditionals (#ifdef-style) are 
>also very useful, but soon we need a whole programming language.

The specific use case I have in mind for that feature is merely avoiding 
the repetition of lengthy base directory names.  However, it's not a necessity.


>>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.
>
>That's just an XML format, right?  A painfully verbose format if I 
>remember, even for XML.

I'm referring to this format, which is even simpler than ConfigParser, and 
rather more rigorously defined, including the expected encoding and support 
for Unicode:

http://java.sun.com/j2se/1.3/docs/api/java/util/Properties.html#load(java.io.InputStream)

It does have some features that are less desirable, like case-sensitivity, 
backslash-escapes, and the fact that its encoding is only friendly to 
Latin-1 users.  Also, it's likely to become quite verbose if a given 
application or server defines lots of configuration keys.  On the other 
hand, it could be a good thing to discourage people from putting lots of 
application configuration in the deployment file, instead of just using it 
primarily to locate to the application's own configuration files.