Added some actual content

This commit is contained in:
Andrew M. Kuchling 2000-10-29 00:16:37 +00:00
parent 91c2029e89
commit 518474ed77
1 changed files with 121 additions and 0 deletions

View File

@ -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: