python-peps/pep-0222.txt

PEP: 222
Title: Web Library Enhancements
Version: $Revision$
Author: akuchlin@mems-exchange.org (Andrew Kuchling)
Status: Active
Type: Standards Track
Python-Version: 2.1
Created: 18-Aug-2000
Post-History:


Abstract

    This PEP proposes a set of enhancements to the CGI development
    facilities in the Python standard library.  Enhancements might be
    new features, new modules for tasks such as cookie support, or
    removal of obsolete code.

    The intent is to incorporate the proposals emerging from this
    document into Python 2.1, due to be released in the first half of
    2001.


Proposed Changes

    This section lists changes that have been suggested, but about
    which no firm decision has yet been made.  In the final version of
    this PEP, this section should be empty, as all the changes should
    be classified as accepted or rejected.

    fcgi.py : A new module adding support for the FastCGI protocol

    Better debugging support for CGIs from the Unix command line.
    Using Perl's CGI.pm [1], if you run a script from the command
    line, you can enter name=value pairs on standard input.
    cgimodel [2] provides this already.

    Should the existing cgi.py be deprecated and everything moved into
    a 'web' or 'cgi' package?  That would allow removing some
    backward-compatibility cruft.

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

    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.

    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

    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.

    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?)

    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.

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

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

    Dictionary-related utility classes: NoKeyErrors (returns an empty
    string, never a KeyError), PartialStringSubstitution (returns 
    the original key string, never a KeyError)


    
New Modules

    This section lists details about entire new packages or modules
    that should be added to the Python standard library.


Major Changes to Existing Modules

    This section lists details of major changes to existing modules,
    whether in implementation or in interface.  The changes in this
    section therefore carry greater degrees of risk, either in
    introducing bugs or a backward incompatibility.
    

Minor Changes to Existing Modules

    This section lists details of minor changes to existing modules.
    These changes should have relatively small implementations, and
    have little risk of introducing incompatibilities with previous
    versions.


Rejected Changes

    The changes listed in this section were proposed for Python 2.1,
    but were rejected as unsuitable.  For each rejected change, a
    rationale is given describing why the change was deemed
    inappropriate.


Copyright

    This document has been placed in the public domain.


References and Footnotes

    [1] CGI.pm:

    [2]   http://www.embl-heidelberg.de/~chenna/pythonpages/



Local Variables:
mode: indented-text
indent-tabs-mode: nil
End: