[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 everyw
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 g
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 appl
I wasn't there when PEP-333 was written, nor have I any implication in
any Python development, but here are my thoughts:
2007/12/7, Alan Kennedy:
>
> I think it's worth pointing out the reason for the current restriction
> to iso-8859-1 is *because* python did not have a bytes type at the
> time t
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, whe
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 str
