On Thu, Sep 16, 2010 at 4:58 PM, Armin Ronacher <armin.ronac...@active-4.com > wrote:
> - 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 listed. - web3.errors > > 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
_______________________________________________ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com