Fill out the proposed interface some more.
Remove some items that have been taken care of.
This commit is contained in:
parent
11a0deaf25
commit
037733d457
108
pep-0222.txt
108
pep-0222.txt
|
@ -6,7 +6,7 @@ Status: Active
|
||||||
Type: Standards Track
|
Type: Standards Track
|
||||||
Python-Version: 2.1
|
Python-Version: 2.1
|
||||||
Created: 18-Aug-2000
|
Created: 18-Aug-2000
|
||||||
Post-History:
|
Post-History: 22-Dec-2000
|
||||||
|
|
||||||
|
|
||||||
Abstract
|
Abstract
|
||||||
|
@ -21,29 +21,13 @@ Abstract
|
||||||
2001.
|
2001.
|
||||||
|
|
||||||
|
|
||||||
Proposed Changes
|
Open Issues
|
||||||
|
|
||||||
This section lists changes that have been suggested, but about
|
This section lists changes that have been suggested, but about
|
||||||
which no firm decision has yet been made. In the final version of
|
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
|
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.
|
|
||||||
Robin Dunn's code needs to be ported to Windows, though.
|
|
||||||
|
|
||||||
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
|
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
|
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
|
find the time to do this right, so I end up reading cgi.py's temp
|
||||||
|
@ -52,26 +36,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: 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: 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
|
||||||
|
@ -81,9 +45,6 @@ Proposed Changes
|
||||||
|
|
||||||
Utility function: build a query string from a list of 2-tuples
|
Utility function: build a query string from a list of 2-tuples
|
||||||
|
|
||||||
Higher-level frameworks: add something like Webware or Zope's
|
|
||||||
HTTPReqest/HTTPResponse objects.
|
|
||||||
|
|
||||||
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)
|
||||||
|
@ -95,6 +56,8 @@ New Modules
|
||||||
This section lists details about entire new packages or modules
|
This section lists details about entire new packages or modules
|
||||||
that should be added to the Python standard library.
|
that should be added to the Python standard library.
|
||||||
|
|
||||||
|
* fcgi.py : A new module adding support for the FastCGI protocol.
|
||||||
|
Robin Dunn's code needs to be ported to Windows, though.
|
||||||
|
|
||||||
Major Changes to Existing Modules
|
Major Changes to Existing Modules
|
||||||
|
|
||||||
|
@ -103,6 +66,8 @@ Major Changes to Existing Modules
|
||||||
section therefore carry greater degrees of risk, either in
|
section therefore carry greater degrees of risk, either in
|
||||||
introducing bugs or a backward incompatibility.
|
introducing bugs or a backward incompatibility.
|
||||||
|
|
||||||
|
The cgi.py module would be deprecated. (XXX A new module or
|
||||||
|
package name hasn't been chosen yet: 'web'? 'cgilib'?)
|
||||||
|
|
||||||
Minor Changes to Existing Modules
|
Minor Changes to Existing Modules
|
||||||
|
|
||||||
|
@ -132,14 +97,12 @@ Rejected Changes
|
||||||
|
|
||||||
Proposed Interface
|
Proposed Interface
|
||||||
|
|
||||||
XXX open issues: naming convention (studlycaps or underline-separated?);
|
XXX open issues: naming convention (studlycaps or
|
||||||
no interface for file uploads yet; need to look at all the various
|
underline-separated?); need to look at the cgi.parse*() functions
|
||||||
packages to see if there's anything else missing; need to look at
|
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
|
||||||
# HTTPResponse class.
|
# HTTPResponse class.
|
||||||
|
@ -168,12 +131,12 @@ Proposed Interface
|
||||||
pass
|
pass
|
||||||
|
|
||||||
def setCookie(self, name, value,
|
def setCookie(self, name, value,
|
||||||
path = XXX, # What to use as defaults?
|
path = '/',
|
||||||
comment = XXX,
|
comment = None,
|
||||||
domain = XXX,
|
domain = None,
|
||||||
max-age = XXX,
|
max-age = None,
|
||||||
expires = XXX,
|
expires = None,
|
||||||
secure = XXX
|
secure = 0
|
||||||
):
|
):
|
||||||
"Set a cookie"
|
"Set a cookie"
|
||||||
pass
|
pass
|
||||||
|
@ -194,21 +157,24 @@ Proposed Interface
|
||||||
"Return a string representation useful for debugging"
|
"Return a string representation useful for debugging"
|
||||||
pass
|
pass
|
||||||
|
|
||||||
# XXX methods for specific classes of error:serverError, badRequest, etc.?
|
# XXX methods for specific classes of error:serverError,
|
||||||
|
# badRequest, etc.?
|
||||||
|
|
||||||
|
|
||||||
class Request:
|
class Request:
|
||||||
|
|
||||||
"""
|
"""
|
||||||
Attributes:
|
Attributes:
|
||||||
|
|
||||||
|
XXX should these be dictionaries, or dictionary-like objects?
|
||||||
.headers : dictionary containing HTTP headers
|
.headers : dictionary containing HTTP headers
|
||||||
.cookies : dictionary of cookies
|
.cookies : dictionary of cookies
|
||||||
.form : data from the form
|
.fields : data from the form
|
||||||
.env : environment dictionary
|
.env : environment dictionary
|
||||||
"""
|
"""
|
||||||
|
|
||||||
def __init__(self, environ=os.environ, stdin=sys.stdin,
|
def __init__(self, environ=os.environ, stdin=sys.stdin,
|
||||||
keep_blank_values=0, strict_parsing=0):
|
keep_blank_values=1, strict_parsing=0):
|
||||||
"""Initialize the request object, using the provided environment
|
"""Initialize the request object, using the provided environment
|
||||||
and standard input."""
|
and standard input."""
|
||||||
pass
|
pass
|
||||||
|
@ -221,12 +187,20 @@ Proposed Interface
|
||||||
pass
|
pass
|
||||||
|
|
||||||
def getField(self, name, default=None):
|
def getField(self, name, default=None):
|
||||||
|
"Return field's value as a string (even if it's an uploaded file)"
|
||||||
pass
|
pass
|
||||||
|
|
||||||
|
def getUploadedFile(self, name):
|
||||||
|
"""Returns a file object that can be read to obtain the contents
|
||||||
|
of an uploaded file. XXX should this report an error if the
|
||||||
|
field isn't actually an uploaded file? Or should it wrap
|
||||||
|
a StringIO around simple fields for consistency?
|
||||||
|
"""
|
||||||
|
|
||||||
def getURL(self, n=0, query_string=0):
|
def getURL(self, n=0, query_string=0):
|
||||||
"""Return the URL of the current request, chopping off 'n' path
|
"""Return the URL of the current request, chopping off 'n' path
|
||||||
components from the right. Eg. if the URL is
|
components from the right. Eg. if the URL is
|
||||||
"http://foo.com/bar/baz/qux", n=2 would return
|
"http://foo.com/bar/baz/quux", n=2 would return
|
||||||
"http://foo.com/bar". Does not include the query string (if
|
"http://foo.com/bar". Does not include the query string (if
|
||||||
any)
|
any)
|
||||||
"""
|
"""
|
||||||
|
@ -246,7 +220,8 @@ Proposed Interface
|
||||||
"String representation suitable for debugging output"
|
"String representation suitable for debugging output"
|
||||||
pass
|
pass
|
||||||
|
|
||||||
# Possibilities?
|
# Possibilities? I don't know if these are worth doing in the
|
||||||
|
# basic objects.
|
||||||
def getBrowser(self):
|
def getBrowser(self):
|
||||||
"Returns Mozilla/IE/Lynx/Opera/whatever"
|
"Returns Mozilla/IE/Lynx/Opera/whatever"
|
||||||
|
|
||||||
|
@ -254,13 +229,17 @@ Proposed Interface
|
||||||
"Return true if this is an SSLified request"
|
"Return true if this is an SSLified request"
|
||||||
|
|
||||||
|
|
||||||
def wrapper(func, logfile=None):
|
# Module-level function
|
||||||
|
def wrapper(func, logfile=sys.stderr):
|
||||||
"""
|
"""
|
||||||
Calls the function 'func', passing it the arguments
|
Calls the function 'func', passing it the arguments
|
||||||
(request, response, logfile). Exceptions are trapped and
|
(request, response, logfile). Exceptions are trapped and
|
||||||
sent to the file 'logfile'.
|
sent to the file 'logfile'.
|
||||||
"""
|
"""
|
||||||
pass
|
# This wrapper will detect if it's being called from the command-line,
|
||||||
|
# and if so, it will run in a debugging mode; name=value pairs
|
||||||
|
# can be entered on standard input to set field values.
|
||||||
|
# (XXX how to do file uploads in this syntax?)
|
||||||
|
|
||||||
|
|
||||||
Copyright
|
Copyright
|
||||||
|
@ -268,13 +247,6 @@ Copyright
|
||||||
This document has been placed in the public domain.
|
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:
|
||||||
mode: indented-text
|
mode: indented-text
|
||||||
|
|
Loading…
Reference in New Issue