PEP 222 draft

[tlownds at my-deja.com]

In article <slrn947bj1.1rs.amk at 207-172-57-45.s45.tnt2.ann.va.dialup.rcn.com>,
  akuchlin at mems-exchange.org wrote:
>     Utility function: build a query string from a list of 2-tuples
>

Perhaps it would be better to extend urllib.urlencode to handle this case. I
think it should be extended to handle lists as values as well:

>>> urlencode({'x': ['a', 'b']})
'x=%5b%27a%27,+%27b%27%5d'

would be:

'x=a&x=b'

>     The cgi.py module would be deprecated.  (XXX A new module or
>     package name hasn't been chosen yet: 'web'?  'cgilib'?)
>

cgilib gets my vote.

>     * An HTML generation module is not part of this PEP.  Several such
>       modules exist, ranging from HTMLgen's purely programming
>       interface to ASP-inspired simple templating to DTML's complex
>       templating.  There's no indication of which templating module to
>       enshrine in the standard library, and that probably means that
>       no module should be so chosen.
>

There are more ASP-like modules out there than other types...

>     Parsing functions: carry over most of the parse* functions from
>     cgi.py
>

It would be really nice to change the main parse-form-input function to
return a dictionary of plain strings instead of the FieldStorage instances.
When a file is uploaded, a FieldStorage instance for that value makes sense.
You've suggested this before, I may have missed it in your PEP.

>
>     # Module-level function
>     def wrapper(func, logfile=sys.stderr):
>         """
>         Calls the function 'func', passing it the arguments
>         (request, response, logfile).  Exceptions are trapped and
>         sent to the file 'logfile'.
>         """
>         # This wrapper will detect if it's being called from the command-line,
>         # and if so, it will run in a debugging mode; name=value pairs
>         # can be entered on standard input to set field values.
>         # (XXX how to do file uploads in this syntax?)
>

Regarding debugging: A command-line debugging ability is very useful! But why
tie that feature to the wrapper feature? You can put it in the
parse-form-input function. Also, allow name=value pairs as command-line
arguments. name=value pairs would still be read even with command-line
arguments, unless a final command-line argument "go" is present.

One debugging feature that would be very useful in a wrapper, is a way to
start pdb either right away or at an exception.

Your wrapper passes (request, response, logfile) - why not pass an object
with .request, .response, and .logfile attributes. Using a tuple now makes it
harder to extend later. A cgi.log-like method on that "context" object would
be useful too!

-Tony Lownds



Sent via Deja.com
http://www.deja.com/