[Web-SIG] PEP 444 (aka Web3)
ianb at colorstudy.com
Fri Sep 17 03:43:25 CEST 2010
On Thu, Sep 16, 2010 at 4:58 PM, Armin Ronacher <armin.ronacher at active-4.com
> - Bytes values in the environment:
> HTTP transmits bytes, that's a fact we can't change. When we go
> with native strings we will go with unicode on 3.x This has the
> following implications:
> - getting the right path info requires a decode + an encode
> unless you are assuming latin1.
Not if you are working with the URL-encoded paths.
> - same as above for the script name and cookie header
Cookie is weird. If that one header could be bytes, that'd be great... but
special-casing Cookie/Set-Cookie is too hard/weird.
Plus handling Cookie/Set-Cookie as Latin1 is just one more line of code
(well, two, one for each header).
When going with unicode strings on 3.x for environ values, we would
> have to do the same for outgoing values which makes middlewares a lot
> harder to write:
All response headers handle encoded URLs (e.g., Location), so
SCRIPT_NAME/PATH_INFO issues don't come into play. Set-Cookie could be an
issue, though only really when someone wants to replicate an external
system's weird cookies -- except for legacy issues it's best for application
developers to stick to ASCII cookies (URL-encoding cookie values is a
popular way of doing this).
I don't know of any other header (or the status) that would reasonably cause
a problem. And I'm not glossing over corner cases -- I'm generally very
aware and concerned with legacy issues, and interacting with legacy
systems. There just aren't any here except for the resolvable issues I've
> I think Ian raised concern that it's specified to support unicode
> only. I don't think we should change that to accepting either bytes
> or unicode is a good idea on Python 3 where there is no stream in
> the language or standard library that accepts both at the same time.
> An implementation for 2.x could support both, but I don't know if
> there is a usecase for that. In general though I have to say that
> very few people use wsgi.errors currently, so I don't think this is
> a real issue anyways.
It's more of an issue under Python 2, it could probably be ignored with
Python 3. Under Python 2 when you have some error condition it's really
frustrating to encounter some unicode error with the logging of that error
(often covering up the original error).
Ian Bicking | http://blog.ianbicking.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Web-SIG