Fill out the proposed interface some more.

Remove some items that have been taken care of.
This commit is contained in:
Andrew M. Kuchling 2000-12-22 20:35:20 +00:00
parent 11a0deaf25
commit 037733d457
1 changed files with 44 additions and 72 deletions

View File

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