iSharkFly-Open
/
python-peps
mirror of https://github.com/python/peps.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

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
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

116
pep-0222.txt
View File

@ -6,7 +6,7 @@ Status: Active
Type: Standards Track
Python-Version: 2.1
Created: 18-Aug-2000
Post-History:
Post-History: 22-Dec-2000
Abstract
@ -21,29 +21,13 @@ Abstract
2001.
Proposed Changes
Open Issues
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.
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
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
@ -52,26 +36,6 @@ Proposed Changes
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: 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
@ -81,9 +45,6 @@ Proposed Changes
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
string, never a KeyError), PartialStringSubstitution (returns
the original key string, never a KeyError)
@ -95,6 +56,8 @@ New Modules
This section lists details about entire new packages or modules
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
@ -102,7 +65,9 @@ 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.
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
@ -132,14 +97,12 @@ Rejected Changes
Proposed Interface
XXX open issues: naming convention (studlycaps or underline-separated?);
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
the cgi.parse*() functions and see if they can be simplified, too.
XXX open issues: naming convention (studlycaps or
underline-separated?); need to look at 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
# HTTPResponse class.
@ -168,12 +131,12 @@ Proposed Interface
pass
def setCookie(self, name, value,
path = XXX, # What to use as defaults?
comment = XXX,
domain = XXX,
max-age = XXX,
expires = XXX,
secure = XXX
path = '/',
comment = None,
domain = None,
max-age = None,
expires = None,
secure = 0
):
"Set a cookie"
pass
@ -194,21 +157,24 @@ Proposed Interface
"Return a string representation useful for debugging"
pass
# XXX methods for specific classes of error:serverError, badRequest, etc.?
# XXX methods for specific classes of error:serverError,
# badRequest, etc.?
class Request:
"""
Attributes:
Attributes:
XXX should these be dictionaries, or dictionary-like objects?
.headers : dictionary containing HTTP headers
.cookies : dictionary of cookies
.form : data from the form
.fields : data from the form
.env : environment dictionary
"""
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
and standard input."""
pass
@ -221,12 +187,20 @@ Proposed Interface
pass
def getField(self, name, default=None):
"Return field's value as a string (even if it's an uploaded file)"
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):
"""Return the URL of the current request, chopping off 'n' path
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
any)
"""
@ -246,21 +220,26 @@ Proposed Interface
"String representation suitable for debugging output"
pass
# Possibilities?
# Possibilities? I don't know if these are worth doing in the
# basic objects.
def getBrowser(self):
"Returns Mozilla/IE/Lynx/Opera/whatever"
def isSecure(self):
"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
(request, response, logfile). Exceptions are trapped and
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
@ -268,13 +247,6 @@ 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:
mode: indented-text