Various small changes; still not complete...
This commit is contained in:
parent
34fe472b9e
commit
777bc87f27
26
pep-0222.txt
26
pep-0222.txt
|
@ -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
|
||||||
|
|
||||||
|
@ -138,6 +136,8 @@ Proposed Interface
|
||||||
no interface for file uploads yet; need to look at all the various
|
no interface for file uploads yet; need to look at all the various
|
||||||
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
|
||||||
|
|
||||||
|
|
Loading…
Reference in New Issue