[Web-SIG] WSGI adoption

[Ian Bicking]

Phillip J. Eby wrote:
> 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?

Well, maybe we're thinking about this differently.  I think it's 
pycoimportant to be able to take several files and combine them for 
configuration; e.g., site and application configuration files.  But just 
for deployment, that's probably not as interesting.  It depends how 
expansive "deployment" is.

Maybe it's fine if the deployment configuration is functionally simple, 
if we can reload it into a more complete system later.  In which case it 
would be good to define the format well.

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

If the file is meant to be human editable, it should preserve some 
structure in case of editing.  I can't stand tools that mangle your 
files, unless that tool truly *owns* the file (e.g., some custom XML file).

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

iniparser is one implementation of semantics, though not particularly 
formally specified.  If I was to specify it, I think it'd go like:

A file is parsed line-by-line.

A section is a line starting with "[", ignoring whitespace.  This line 
must end with "]" (ignoring whitespace), and the whitespace-stripped 
contents are the "section name".  The beginning of one section is the 
end of the last section; there is no explicit way to end a section.

A comment is a line starting with # or ;, ignoring whitespace.

Blank lines are ignored.

An assignment is any other line.  An assignment must contain a = or a :; 
the first of these characters found is used.  The text before the 
separator, stripped of whitespace, is the key name.  The text after, 
stripped of whitespace, is the key value.

An assignment can span multiple lines if the following lines are 
indented, i.e., start with whitespace.  The first unindented line (i.e., 
a line that doesn't start with whitespace) or the first blank line ends 
the assignment.  The text is the concatenation of all lines.  (Here's 
where I'm unclear; including newlines?  What happens to the leading 
whitespace?)


Well, that probably doesn't match ConfigParser entirely.  I believe it 
requires that all sections and assignments have non-whitespace in the 
first column, but I'm not sure about that.  It also still doesn't deal 
with encoding, or allow for any kind of quoting.

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

The judicious use of relative paths can help.  I.e., specify what each 
path is relative to, and some paths in the configuration may be relative 
to other paths.

>>> 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's nice in that it can easily be used with any unicode string value, 
though its keys aren't as flexible.

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


-- 
Ian Bicking  /  ianb at colorstudy.com  / http://blog.ianbicking.org