PEP 222: Web programming improvements

[Erno Kuusela]

>>>>> "Andrew" == Andrew Kuchling <akuchlin at mems-exchange.org> writes:

    Andrew> A while ago I proposed a PEP to improve Python's
    Andrew> facilities for Web programming:

    Andrew> http://python.sourceforge.net/peps/pep-0222.html

[quoting from the pep]

> Proposed Changes
> 
 >[...]
>     fcgi.py : A new module adding support for the FastCGI protocol

fastcgi is a good idea in principle. however it doesn't seem to be very
widely used and the apache mod_fastcgi non-free :/

>     cgi.py: keep_blank_values should be on by default. The 'if
>     form.has_key()/if form[key].value' nested syntax is unnecessarily
>     convoluted.

and at least to my mind there is a semantic difference
between "field doesn't exist" and "field is set to ''".

>     cgi.py: We should not be told to create our own subclass just so
>     we can handle file uploads. As a practical matter, I have yet to
>     find the time to do this right, so I end up reading cgi.py's temp
>     file into, at best, another file. Some of our legacy code actually
>     reads it into a second temp file, then into a final destination!
>     And even if we did, that would mean creating yet another object
>     with its __init__ call and associated overhead.

i'm not quite what sure what you are saying :) the
current cgi py doesn't require subclassing i don't think.
i'd like interfaces to both return the uploaded file as
a string and write it to an existing file object.

(or just the latter, users can use stringio if a string is wanted)

is it possible to have the data go straight from the network
into the user-supplied file object? that would relieve the
need for internal temp files.

>     cgi.py: Ideally, the pseudo-dictionary syntax would go away. It
>     seems to me that the main reason it is there is to accomodate
> 
>         form['field'].file syntax. How about the following:
>         form['field'] = '' #no values for key
>         form['field'] = 'string' #one value in submission for key
>         form['field'] = ['string', 'string', ....] #multiple values
>         form['field'] = {'fileName':'remote/path',
>                       'binaryValue':'@UIHJBV29489erht...'} #one file
>         form['field'] = [{'fileName':'remote/path',
>                       'binaryValue':'@UIHJBV29489erht...'},
>                      {'fileName':'another/path',
>                       'binaryValue':'7r7w7@@@@'}] #multiple files

seems ok to me.

hm... usually the user knows what sort of field he is prepared to
handle. currently you need extra checking if you want
pretty error messages for lists/files where simple fields
were expected.

maybe there could be prototypes for form fields?
formpt['field1'] = FieldPrototype(single=1, conv='numeric'),
and maybe allow a converter function.

you could also do it like zope (name the field 'field1:int').

maybe it is too elaborate.

>     cgi.py: I'd prefer "input" or "submission" for the suggested
>     FieldStorage() name. The html page into which the data represented
>     by FieldStorage() is input is commonly known as a "form", which
>     means that when someone refers to "the form" you aren't always
>     sure what they are talking about.

yes.

>     cgi.py: Allow a combination of query data and POST data.
>     Currently, if there is POST data, then any query data encoded in
>     the URL is ignored.  It would be more convenient if the data from
>     those two sources were merged into one dictionary. (XXX but is
>     this standard at all?)

i've never seen this done. i wouldn't do it.

>     cgi.py: Currently, query data with no `=' are ignored.  Even if
>     keep_blank_values is set, queries like `...?value=&...' are
>     returned with blank values but queries like `...?value&...' are
>     completely lost.  It would be great if such data were made
>     available through the FieldStorage interface, either as entries
>     with None as values, or in a separate list.

i think query strings like that are invalid? an exception should
be raised.

>     Higher-level frameworks: add something like Webware or Zope's
>     HTTPReqest/HTTPResponse objects.

yes, this would be handy.

>     An HTML templating module.  (But which one?  There's no clear, or
>     even vague, indication of which templating module to enshrine.)

as long as it's not dtml... ;)

i love ptl.

  -- erno