Various small changes; still not complete...

This commit is contained in:
Andrew M. Kuchling 2000-12-18 03:01:23 +00:00
parent 34fe472b9e
commit 777bc87f27
1 changed files with 13 additions and 13 deletions

View File

@ -28,7 +28,8 @@ Proposed Changes
this PEP, this section should be empty, as all the changes should this PEP, this section should be empty, as all the changes should
be classified as accepted or rejected. be classified as accepted or rejected.
fcgi.py : A new module adding support for the FastCGI protocol fcgi.py : A new module adding support for the FastCGI protocol.
Robin Dunn's code needs to be ported to Windows, though.
Better debugging support for CGIs from the Unix command line. Better debugging support for CGIs from the Unix command line.
Using Perl's CGI.pm [1], if you run a script from the command Using Perl's CGI.pm [1], if you run a script from the command
@ -51,8 +52,6 @@ Proposed Changes
And even if we did, that would mean creating yet another object And even if we did, that would mean creating yet another object
with its __init__ call and associated overhead. with its __init__ call and associated overhead.
cgi.py: Delete the references to self.lines for file uploads
cgi.py: Ideally, the pseudo-dictionary syntax would go away. It cgi.py: Ideally, the pseudo-dictionary syntax would go away. It
seems to me that the main reason it is there is to accomodate seems to me that the main reason it is there is to accomodate
@ -73,12 +72,6 @@ Proposed Changes
means that when someone refers to "the form" you aren't always means that when someone refers to "the form" you aren't always
sure what they are talking about. 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 cgi.py: Currently, query data with no `=' are ignored. Even if
keep_blank_values is set, queries like `...?value=&...' are keep_blank_values is set, queries like `...?value=&...' are
returned with blank values but queries like `...?value&...' are returned with blank values but queries like `...?value&...' are
@ -91,9 +84,6 @@ Proposed Changes
Higher-level frameworks: add something like Webware or Zope's Higher-level frameworks: add something like Webware or Zope's
HTTPReqest/HTTPResponse objects. 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 Dictionary-related utility classes: NoKeyErrors (returns an empty
string, never a KeyError), PartialStringSubstitution (returns string, never a KeyError), PartialStringSubstitution (returns
the original key string, never a KeyError) the original key string, never a KeyError)
@ -129,8 +119,16 @@ Rejected Changes
rationale is given describing why the change was deemed rationale is given describing why the change was deemed
inappropriate. inappropriate.
* None yet * 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.
* cgi.py: Allowing a combination of query data and POST data.
This doesn't seem to be standard at all, and therefore is
dubious practice.
Proposed Interface Proposed Interface
@ -139,6 +137,8 @@ Proposed Interface
packages to see if there's anything else missing; need to look at packages to see if there's anything else missing; need to look at
the cgi.parse*() functions and see if they can be simplified, too. the cgi.parse*() functions and see if they can be simplified, too.
XXX file uploads
Parsing functions: carry over most of the parse* functions from cgi.py Parsing functions: carry over most of the parse* functions from cgi.py
# The Response class borrows most of its methods from Zope's # The Response class borrows most of its methods from Zope's