[Python-checkins] python/nondist/peps pep-0333.txt,1.10,1.11

[pje at users.sourceforge.net]

Update of /cvsroot/python/python/nondist/peps
In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv18247

Modified Files:
	pep-0333.txt 
Log Message:
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!

Index: pep-0333.txt
===================================================================
RCS file: /cvsroot/python/python/nondist/peps/pep-0333.txt,v
retrieving revision 1.10
retrieving revision 1.11
diff -u -d -r1.10 -r1.11
--- pep-0333.txt	14 Sep 2004 06:02:28 -0000	1.10
+++ pep-0333.txt	15 Sep 2004 17:05:22 -0000	1.11
@@ -756,6 +756,22 @@
 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 @@
    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 @@
 
 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 @@
 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.