Clarify the meaning of "string" for platforms where 'str' objects can
contain Unicode (e.g. Jython, IronPython, Python 3000, etc.), per discussion at: http://mail.python.org/pipermail/web-sig/2004-September/000860.html Also, misc. copy edits. Only one open issue left!
This commit is contained in:
parent
dc2bfe867a
commit
5dc9fcb7ae
32
pep-0333.txt
32
pep-0333.txt
|
@ -756,6 +756,22 @@ as headers **must** follow RFC 2616 with respect to encoding. That
|
|||
is, they must either be ISO-8859-1 characters, or use RFC 2047 MIME
|
||||
encoding.
|
||||
|
||||
On Python platforms where the ``str`` or ``StringType`` type is in
|
||||
fact Unicode-based (e.g. Jython, IronPython, Python 3000, etc.), all
|
||||
"strings" referred to in this specification must contain only
|
||||
code points representable in ISO-8859-1 encoding (``\u0000`` through
|
||||
``\u00FF``, inclusive). It is a fatal error for an application to
|
||||
supply strings containing any other Unicode character or code point.
|
||||
Similarly, servers and gateways **must not** supply
|
||||
strings to an application containing any other Unicode characters.
|
||||
|
||||
Again, all strings referred to in this specification **must** be
|
||||
of type ``str`` or ``StringType``, and **must not** be of type
|
||||
``unicode`` or ``UnicodeType``. And, even if a given platform allows
|
||||
for more than 8 bits per character in ``str``/``StringType`` objects,
|
||||
only the lower 8 bits may be used, for any value referred to in
|
||||
this specification as a "string".
|
||||
|
||||
|
||||
Multiple Invocations
|
||||
--------------------
|
||||
|
@ -1223,7 +1239,7 @@ Questions and Answers
|
|||
offering any such value-added services.
|
||||
|
||||
2. Why can you call ``write()`` *and* yield strings/return an
|
||||
iterator? Shouldn't we pick just one way?
|
||||
iterable? Shouldn't we pick just one way?
|
||||
|
||||
If we supported only the iteration approach, then current
|
||||
frameworks that assume the availability of "push" suffer. But, if
|
||||
|
@ -1237,11 +1253,11 @@ Questions and Answers
|
|||
|
||||
3. What's the ``close()`` for?
|
||||
|
||||
When writes are done from during the execution of an application
|
||||
When writes are done during the execution of an application
|
||||
object, the application can ensure that resources are released
|
||||
using a try/finally block. But, if the application returns an
|
||||
iterator, any resources used will not be released until the
|
||||
iterator is garbage collected. The ``close()`` idiom allows an
|
||||
iterable, any resources used will not be released until the
|
||||
iterable is garbage collected. The ``close()`` idiom allows an
|
||||
application to release critical resources at the end of a request,
|
||||
and it's forward-compatible with the support for try/finally in
|
||||
generators that's proposed by PEP 325.
|
||||
|
@ -1347,14 +1363,6 @@ Questions and Answers
|
|||
Open Issues
|
||||
===========
|
||||
|
||||
* Byte strings: future versions of Python may replace today's
|
||||
8-bit strings with some kind of "byte array" type. Some sort
|
||||
of future-proofing would be good to have, and strategies for
|
||||
this should be discussed on Web-SIG and Python-Dev. Nearly
|
||||
every string in WSGI is potentially affected by this, although
|
||||
some contexts should perhaps continue to allow strings as long as
|
||||
they're pure ASCII.
|
||||
|
||||
* Required CGI variables: should we really be requiring all of the
|
||||
variables named? Some of them seem reasonable to be optional.
|
||||
|
||||
|
|
Loading…
Reference in New Issue