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:
Phillip J. Eby 2004-09-15 17:05:22 +00:00
parent dc2bfe867a
commit 5dc9fcb7ae
1 changed files with 20 additions and 12 deletions

View File

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