8000 Convert PEPs 222, 224, 281, 284, 310 (#203) · python/peps@c5881cf · GitHub
[go: up one dir, main page]
Skip to content

Commit c5881cf

Browse files
MariattaMariatta
authored
Convert PEPs 222, 224, 281, 284, 310 (#203)
1 parent 0966f37 commit c5881cf

File tree

5 files changed

+761
-683
lines changed

5 files changed

+761
-683
lines changed

‎pep-0222.txt

Lines changed: 124 additions & 109 deletions
Original file line numberDiff line numberDiff line change
@@ -5,200 +5,213 @@ Last-Modified: $Date$
55
Author: A.M. Kuchling <amk@amk.ca>
66
Status: Deferred
77
Type: Standards Track
8+
Content-Type: text/x-rst
89
Created: 18-Aug-2000
910
Python-Version: 2.1
1011
Post-History: 22-Dec-2000
1112

1213

1314
Abstract
15+
========
1416

15-
This PEP proposes a set of enhancements to the CGI development
16-
facilities in the Python standard library. Enhancements might be
17-
new features, new modules for tasks such as cookie support, or
18-
removal of obsolete code.
17+
This PEP proposes a set of enhancements to the CGI development
18+
facilities in the Python standard library. Enhancements might be
19+
new features, new modules for tasks such as cookie support, or
20+
removal of obsolete code.
21+
22+
The original intent was to make improvements to Python 2.1.
23+
However, there seemed little interest from the Python community,
24+
and time was lacking, so this PEP has been deferred to some future
25+
Python release.
1926

20-
The original intent was to make improvements to Python 2.1.
21-
However, there seemed little interest from the Python community,
22-
and time was lacking, so this PEP has been deferred to some future
23-
Python release.
24-
2527

2628
Open Issues
29+
===========
30+
31+
This section lists changes that have been suggested, but about
32+
which no firm decision has yet been made. In the final version of
33+
this PEP, this section should be empty, as all the changes should
34+
be classified as accepted or rejected.
2735

28-
This section lists changes that have been suggested, but about
29-
which no firm decision has yet been made. In the final version of
30-
this PEP, this section should be empty, as all the changes should
31-
be classified as accepted or rejected.
36+
cgi.py: We should not be told to create our own subclass just so
37+
we can handle file uploads. As a practical matter, I have yet to
38+
find the time to do this right, so I end up reading cgi.py's temp
39+
file into, at best, another file. Some of our legacy code actually
40+
reads it into a second temp file, then into a final destination!
41+
And even if we did, that would mean creating yet another object
42+
with its ``__init__`` call and associated overhead.
3243

33-
cgi.py: We should not be told to create our own subclass just so
34-
we can handle file uploads. As a practical matter, I have yet to
35-
find the time to do this right, so I end up reading cgi.py's temp
36-
file into, at best, another file. Some of our legacy code actually
37-
reads it into a second temp file, then into a final destination!
38-
And even if we did, that would mean creating yet another object
39-
with its __init__ call and associated overhead.
44+
cgi.py: Currently, query data with no ``=`` are ignored. Even if
45+
keep_blank_values is set, queries like ``...?value=&...`` are
46+
returned with blank values but queries like ``...?value&...`` are
47+
completely lost. It would be great if such data were made
48+
available through the ``FieldStorage`` interface, either as entries
49+
with None as values, or in a separate list.
4050

41-
cgi.py: Currently, query data with no `=' are ignored. Even if
42-
keep_blank_values is set, queries like `...?value=&...' are
43-
returned with blank values but queries like `...?value&...' are
44-
completely lost. It would be great if such data were made
45-
available through the FieldStorage interface, either as entries
46-
with None as values, or in a separate list.
51+
Utility function: build a query string from a list of 2-tuples
4752

48-
Utility function: build a query string from a list of 2-tuples
53+
Dictionary-related utility classes: ``NoKeyErrors`` (returns an empty
54+
string, never a ``KeyError``), ``PartialStringSubstitution`` (returns
55+
the original key string, never a ``KeyError``)
4956

50-
Dictionary-related utility classes: NoKeyErrors (returns an empty
51-
string, never a KeyError), PartialStringSubstitution (returns
52-
the original key string, never a KeyError)
5357

5458

55-
5659
New Modules
60+
===========
61+
62+
This section lists details about entire new packages or modules
63+
that should be added to the Python standard library.
5764

58-
This section lists details about entire new packages or modules
59-
that should be added to the Python standard library.
65+
* fcgi.py : A new module adding support for the FastCGI protocol.
66+
Robin Dunn's code needs to be ported to Windows, though.
6067

61-
* fcgi.py : A new module adding support for the FastCGI protocol.
62-
Robin Dunn's code needs to be ported to Windows, though.
6368

6469
Major Changes to Existing Modules
70+
=================================
6571

66-
This section lists details of major changes to existing modules,
67-
whether in implementation or in interface. The changes in this
68-
section therefore carry greater degrees of risk, either in
69-
introducing bugs or a backward incompatibility.
72+
This section lists details of major changes to existing modules,
73+
whether in implementation or in interface. The changes in this
74+
section therefore carry greater degrees of risk, either in
75+
introducing bugs or a backward incompatibility.
76+
77+
The cgi.py module would be deprecated. (XXX A new module or
78+
package name hasn't been chosen yet: 'web'? 'cgilib'?)
7079

71-
The cgi.py module would be deprecated. (XXX A new module or
72-
package name hasn't been chosen yet: 'web'? 'cgilib'?)
7380

7481
Minor Changes to Existing Modules
82+
=================================
7583

76-
This section lists details of minor changes to existing modules.
77-
These changes should have relatively small implementations, and
78-
have little risk of introducing incompatibilities with previous
79-
versions.
84+
This section lists details of minor changes to existing modules.
85+
These changes should have relatively small implementations, and
86+
have little risk of introducing incompatibilities with previous
87+
versions.
8088

8189

8290
Rejected Changes
91+
================
92+
93+
The changes listed in this section were proposed for Python 2.1,
94+
but were rejected as unsuitable. For each rejected change, a
95+
rationale is given describing why the change was deemed
96+
inappropriate.
8397

84-
The changes listed in this section were proposed for Python 2.1,
85-
but were rejected as unsuitable. For each rejected change, a
86-
rationale is given describing why the change was deemed
87-
inappropriate.
98+
* An HTML generation module is not part of this PEP. Several such
99+
modules exist, ranging from HTMLgen's purely programming
100+
interface to ASP-inspired simple templating to DTML's complex
101+
templating. There's no indication of which templating module to
102+
enshrine in the standard library, and that probably means that
103+
no module should be so chosen.
88104

89-
* An HTML generation module is not part of this PEP. Several such
90-
modules exist, ranging from HTMLgen's purely programming
91-
interface to ASP-inspired simple templating to DTML's complex
92-
templating. There's no indication of which templating module to
93-
enshrine in the standard library, and that probably means that
94-
no module should be so chosen.
105+
* cgi.py: Allowing a combination of query data and POST data.
106+
This doesn't seem to be standard at all, and therefore is
107+
dubious practice.
95108

96-
* cgi.py: Allowing a combination of query data and POST data.
97-
This doesn't seem to be standard at all, and therefore is
98-
dubious practice.
99109

100110
Proposed Interface
111+
==================
101112

102-
XXX open issues: naming convention (studlycaps or
103-
underline-separated?); need to look at the cgi.parse*() functions
104-
and see if they can be simplified, too.
113+
XXX open issues: naming convention (studlycaps or
114+
underline-separated?); need to look at the ``cgi.parse*()`` functions
115+
and see if they can be simplified, too.
116+
117+
Parsing functions: carry over most of the ``parse*`` functions from
118+
cgi.py
119+
120+
::
105121

106-
Parsing functions: carry over most of the parse* functions from
107-
cgi.py
108-
109122
# The Response class borrows most of its methods from Zope's
110123
# HTTPResponse class.
111-
124+
112125
class Response:
113126
"""
114127
Attributes:
115128
status: HTTP status code to return
116129
headers: dictionary of response headers
117130
body: string containing the body of the HTTP response
118131
"""
119-
132+
120133
def __init__(self, status=200, headers={}, body=""):
121134
pass
122-
135+
123136
def setStatus(self, status, reason=None):
124137
"Set the numeric HTTP response code"
125138
pass
126-
139+
127140
def setHeader(self, name, value):
128141
"Set an HTTP header"
129142
pass
130-
143+
131144
def setBody(self, body):
132145
"Set the body of the response"
133146
pass
134-
147+
135148
def setCookie(self, name, value,
136-
path = '/',
137-
comment = None,
138-
domain = None,
149+
path = '/',
150+
comment = None,
151+
domain = None,
139152
max-age = None,
140153
expires = None,
141154
secure = 0
142155
):
143156
"Set a cookie"
144157
pass
145-
158+
146159
def expireCookie(self, name):
147160
"Remove a cookie from the user"
148161
pass
149-
162+
150163
def redirect(self, url):
151164
"Redirect the browser to another URL"
152165
pass
153-
166+
154167
def __str__(self):
155168
"Convert entire response to a string"
156169
pass
157-
170+
158171
def dump(self):
159172
"Return a string representation useful for debugging"
160173
pass
161-
162-
# XXX methods for specific classes of error:serverError,
174+
175+
# XXX methods for specific classes of error:serverError,
163176
# badRequest, etc.?
164-
165-
177+
178+
166179
class Request:
167-
180+
168181
"""
169-
Attributes:
182+
Attributes:
170183

171184
XXX should these be dictionaries, or dictionary-like objects?
172185
.headers : dictionary containing HTTP headers
173186
.cookies : dictionary of cookies
174187
.fields : data from the form
175188
.env : environment dictionary
176189
"""
177-
190+
178191
def __init__(self, environ=os.environ, stdin=sys.stdin,
179192
keep_blank_values=1, strict_parsing=0):
180193
"""Initialize the request object, using the provided environment
181194
and standard input."""
182195
pass
183-
196+
184197
# Should people just use the dictionaries directly?
185198
def getHeader(self, name, default=None):
186199
pass
187-
200+
188201
def getCookie(self, name, default=None):
189202
pass
190-
203+
191204
def getField(self, name, default=None):
192205
"Return field's value as a string (even if it's an uploaded file)"
193206
pass
194-
207+
195208
def getUploadedFile(self, name):
196209
"""Returns a file object that can be read to obtain the contents
197-
of an uploaded file. XXX should this report an error if the
210+
of an uploaded file. XXX should this report an error if the
198211
field isn't actually an uploaded file? Or should it wrap
199212
a StringIO around simple fields for consistency?
200213
"""
201-
214+
202215
def getURL(self, n=0, query_string=0):
203216
"""Return the URL of the current request, chopping off 'n' path
204217
components from the right. Eg. if the URL is
@@ -209,48 +222,50 @@ Proposed Interface
209222

210223
def getBaseURL(self, n=0):
211224
"""Return the base URL of the current request, adding 'n' path
212-
components to the end to recreate more of the whole URL.
213-
225+
components to the end to recreate more of the whole URL.
226+
214227
Eg. if the request URL is
215228
"http://foo.com/q/bar/baz/qux", n=0 would return
216229
"http://foo.com/", and n=2 "http://foo.com/q/bar".
217-
230+
218231
Returned URL does not include the query string, if any.
219232
"""
220-
233+
221234
def dump(self):
222235
"String representation suitable for debugging output"
223236
pass
224-
225-
# Possibilities? I don't know if these are worth doing in the
237+
238+
# Possibilities? I don't know if these are worth doing in the
226239
# basic objects.
227240
def getBrowser(self):
228241
"Returns Mozilla/IE/Lynx/Opera/whatever"
229-
242+
230243
def isSecure(self):
231244
"Return true if this is an SSLified request"
232-
233245

234-
# Module-level function
246+
247+
# Module-level function
235248
def wrapper(func, logfile=sys.stderr):
236249
"""
237250
Calls the function 'func', passing it the arguments
238251
(request, response, logfile). Exceptions are trapped and
239-
sent to the file 'logfile'.
252+
sent to the file 'logfile'.
240253
"""
241254
# This wrapper will detect if it's being called from the command-line,
242-
# and if so, it will run in a debugging mode; name=value pairs
255+
# and if so, it will run in a debugging mode; name=value pairs
243256
# can be entered on standard input to set field values.
244257
# (XXX how to do file uploads in this syntax?)
245258

246-
259+
247260
Copyright
248-
249-
This document has been placed in the public domain.
261+
=========
262+
263+
This document has been placed in the public domain.
264+
250265

251266

252-
253-
Local Variables:
254-
mode: indented-text
255-
indent-tabs-mode: nil
256-
End:
267+
..
268+
Local Variables:
269+
mode: indented-text
270+
indent-tabs-mode: nil
271+
End:

0 commit comments

Comments
 (0)
0