Use new-style classes in examples. Fix typos.
This commit is contained in:
parent
c29c921482
commit
cf3be960ad
18
pep-0333.txt
18
pep-0333.txt
|
@ -172,7 +172,7 @@ other is a class::
|
|||
return ['Hello world!\n']
|
||||
|
||||
|
||||
class AppClass:
|
||||
class AppClass(object):
|
||||
"""Produce the same output, but using a class
|
||||
|
||||
(Note: 'AppClass' is the "application" here, so calling it
|
||||
|
@ -321,7 +321,7 @@ a block boundary.)
|
|||
|
||||
from piglatin import piglatin
|
||||
|
||||
class LatinIter:
|
||||
class LatinIter(object):
|
||||
|
||||
"""Transform iterated output to piglatin, if it's okay to do so
|
||||
|
||||
|
@ -345,7 +345,7 @@ a block boundary.)
|
|||
else:
|
||||
return self._next()
|
||||
|
||||
class Latinator:
|
||||
class Latinator(object):
|
||||
|
||||
# by default, don't transform output
|
||||
transform = False
|
||||
|
@ -360,7 +360,7 @@ a block boundary.)
|
|||
def start_latin(status, response_headers, exc_info=None):
|
||||
|
||||
# Reset ok flag, in case this is a repeat call
|
||||
transform_ok[:] = []
|
||||
del transform_ok[:]
|
||||
|
||||
for name, value in response_headers:
|
||||
if name.lower() == 'content-type' and value == 'text/plain':
|
||||
|
@ -368,7 +368,7 @@ a block boundary.)
|
|||
# Strip content-length if present, else it'll be wrong
|
||||
response_headers = [(name, value)
|
||||
for name, value in response_headers
|
||||
if name.lower() <> 'content-length'
|
||||
if name.lower() != 'content-length'
|
||||
]
|
||||
break
|
||||
|
||||
|
@ -1305,7 +1305,7 @@ more complex:
|
|||
|
||||
* You may not return a file object and expect it to work as an iterable,
|
||||
since before Python 2.2, files were not iterable. (In general, you
|
||||
shouldn't do this anyway, because it will peform quite poorly most
|
||||
shouldn't do this anyway, because it will perform quite poorly most
|
||||
of the time!) Use ``wsgi.file_wrapper`` or an application-specific
|
||||
file wrapper class. (See `Optional Platform-Specific File Handling`_
|
||||
for more on ``wsgi.file_wrapper``, and an example class you can use
|
||||
|
@ -1371,7 +1371,7 @@ it is not guaranteed that any wrapper created will actually be used.)
|
|||
|
||||
Apart from the handling of ``close()``, the semantics of returning a
|
||||
file wrapper from the application should be the same as if the
|
||||
application had returned ``iter(filelike.read, '')``. In other words,
|
||||
application had returned ``iter(filelike, '')``. In other words,
|
||||
transmission should begin at the current position within the "file"
|
||||
at the time that transmission begins, and continue until the end is
|
||||
reached.
|
||||
|
@ -1390,7 +1390,7 @@ the ``wsgi.file_wrapper`` **must** still return an iterable that wraps
|
|||
are portable across platforms. Here's a simple platform-agnostic
|
||||
file wrapper class, suitable for old (pre 2.2) and new Pythons alike::
|
||||
|
||||
class FileWrapper:
|
||||
class FileWrapper(object):
|
||||
|
||||
def __init__(self, filelike, blksize=8192):
|
||||
self.filelike = filelike
|
||||
|
@ -1581,7 +1581,7 @@ or are on the PEP author's "to-do" list:
|
|||
streams.
|
||||
|
||||
* Optional extensions are being discussed for pausing iteration of an
|
||||
application's ouptut until input is available or until a callback
|
||||
application's output until input is available or until a callback
|
||||
occurs.
|
||||
|
||||
* Add a section about synchronous vs. asynchronous apps and servers,
|
||||
|
|
Loading…
Reference in New Issue