Added some actual content
This commit is contained in:
Andrew M. Kuchling
parent
91c2029e89
commit
518474ed77
121
pep-0222.txt
121
pep-0222.txt
|
|
@ -16,6 +16,127 @@ Abstract
|
||||||
new features, new modules for tasks such as cookie support, or
|
new features, new modules for tasks such as cookie support, or
|
||||||
removal of obsolete code.
|
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:
|
Local Variables:
|
||||||
|
|
|
||||||
Loading…
Reference in New Issue