[Web-SIG] WSGI adoption

[Carlos Ribeiro]

On Thu, 25 Nov 2004 23:22:09 +0000, Alan Kennedy <py-web-sig at xhaus.com> wrote:
> Since I don't have a specific proposal myself, I don't want to criticise
> approaches.
> 
> But on reading the docs for ConfigParser, I think that it doesn't have
> encoding support(?). Meaning that configuring internationalised strings
> will be complex, which will definitely be problematic in a world where
> most filesystems acccept unicode file names, for example.
>
> Python has a simple and clear mechanism for declaring file encodings:
> it's definitely my favoured option.

Adding encoding support for ConfigParser should not be that difficult.
Encoding could be supplied exactly as it is for a Python source file.
Also, as far as I understand it, some of the arguments that apply for
having encoding support built in into Python do not apply to
configuration files; namely, sharing configuration files is not as
important as sharing source files. But I may be mistaken.

> I understand Carlos' arguments against having end-users edit python
> files/write programs to configure their servers. But python code
> containing simple name/value pairs, lists and mappings is also pretty
> simple to read and write.

As soon as you start to use Python files, you open a big door for
abuses and weird problems. I fear that things that really should be
done on the product code itself will start to be done on the
configuration as a kind of "just one more hack". Of course, nobody
will ever remember to remove then after some time.
 
> Maybe we could restrict the structure of such python config files, so
> that framework authors couldn't force users to learn, for example,
> metaclasses to configure their software? It needn't be a
> rigidly-enforced restriction, i.e. checked by an algorithm, but just a
> line-in-the-sand statement in the spec. Something like "WSGI
> configuration files may only contain simple python assignments to single
> objects, lists of objects or dictionaries of objects. They may not
> contain class definitions, function definitions, import statements, etc,
> etc."?

Please don't get me wrong. But as soon as you try to impose
limitations on syntax, we're back on ConfigParser land again; we have
to implement the parser, map values, etc. If we will have to do it,
why not reuse what we already have?

> And lastly, it's got to be said: although we may dislike the awkwardness
> and rigidity of XML, it is almost universally understood, at all levels
> of technical ability. It is universally supported in all python
> environments, and it handles encodings and i18n very gracefully.

There are a number of arguments against XML, the main one being the
fact that isn't exactly readable by a human being; also, the fact that
it's easily broken by a end-user who may do something as simple as
forget to include one slash on the closing tag (and I know how often I
do it :-P).

Don't get me wrong. XML wasn't done for human consumption; it was
conceived for computers, with the nice property that it can be read &
conveniently processed by humans for debugging purposes. Simple XML
files are readable, but... if all that is needed is a simple file,
plain INI is simpler *and* more readable. And as soon as you need to
define a more complex structure that needs XML power, it quickly
becomes unreadable.

-- 
Carlos Ribeiro
Consultoria em Projetos
blog: http://rascunhosrotos.blogspot.com
blog: http://pythonnotes.blogspot.com
mail: carribeiro at gmail.com
mail: carribeiro at yahoo.com