From 518474ed7740d108ce330de31ac062d0d7801e67 Mon Sep 17 00:00:00 2001 From: "Andrew M. Kuchling" Date: Sun, 29 Oct 2000 00:16:37 +0000 Subject: [PATCH] Added some actual content --- pep-0222.txt | 121 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 121 insertions(+) diff --git a/pep-0222.txt b/pep-0222.txt index 52e547a33..491270f4b 100644 --- a/pep-0222.txt +++ b/pep-0222.txt @@ -16,6 +16,127 @@ Abstract 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: