[Alan]
The restriction to iso-8859-1 is really a distraction; iso-8859-1 is
used simply as an identity encoding that also enforces that all
bytes in the string have a value from 0x00 to 0xff, so that they are
suitable for byte-oriented IO. So, in output terms at least, WSGI *is*
a
[Phillip]
WSGI already copes, actually. Note that Jython and IronPython have
this issue today, and see:
http://www.python.org/dev/peps/pep-0333/#unicode-issues
[James]
It would seem very odd, however, for WSGI/python3 to use strings-
restricted-to-0xFF for network I/O while everywhere else
Phillip J. Eby wrote:
So here are my recommendations so far for the addendum to WSGI *1.0* for
Python 3.0 (I expect we can be more strict for WSGI 2.0):
* When running under Python 3, applications SHOULD produce bytes output
and headers
* When running under Python 3, servers and
So here are my recommendations so far for the addendum to WSGI *1.0*
for Python 3.0 (I expect we can be more strict for WSGI 2.0):
* When running under Python 3, applications SHOULD produce bytes
output and headers
* When running under Python 3, servers and gateways MUST accept
strings as
On Dec 7, 2007, at 5:46 PM, Andrew Clover wrote:
OTOH making the dictionaries reflect the underlying OS's conception of
environment variables means users of os.environ and WSGI will have
to be
able to cope with both bytes and unicode, which would also be a big
annoyance.
In summary:
James Y Knight wrote:
In addition, I know of nobody who actually implements RFC 2047
decoding of http header values...nothing really uses it. (of
course I don't know of all implementations out there.)
Certainly no browser supports it, which makes the point moot for WSGI.
Most browsers, when
Adam Atlas [EMAIL PROTECTED] wrote:
I'd say it would be best to only accept `bytes` objects
+1. HTTP is inherently byte-based. Any translation between bytes and
unicode characters should be done at a higher level, by whatever web
framework is living above WSGI.
--
And Clover
mailto:[EMAIL
On Dec 7, 2007, at 2:55 PM, Phillip J. Eby wrote:
* When running under Python 3, servers MUST provide CGI HTTP
variables as strings, decoded from the headers using HTTP standard
encodings (i.e. latin-1 + RFC 2047) (Open question: are there any
CGI or WSGI variables that should NOT be
