On Saturday, July 17, 2010, Ian Bicking <i...@colorstudy.com> wrote: > On Fri, Jul 16, 2010 at 12:28 PM, Chris McDonough <chr...@plope.com> wrote: > > > On Fri, 2010-07-16 at 11:07 -0500, Ian Bicking wrote: > >> And this doesn't help with Python 3: either we have byte values of >> SCRIPT_NAME and PATH_INFO in Python 3, or we have text values. I >> think bytes will be more awkward to port to than text, and >> inconsistent with other WSGI values. If we have text then we have to >> choose an encoding. Latin1 will work, but it will be the exact wrong >> encoding most of the time as UTF-8 is the typical (unlike other >> headers, where Latin1 will mostly be an okay encoding, or as good a >> guess as we have). If we firmly remove these keys then we can avoid >> this choice entirely... and we conveniently also get a better >> representation of the request. > > My $.02: I'd rather lobby the core folks for a string ABC (which we can > hook with a stringlike bytes type) and consider all 3.X releases made so > far "dead to WSGI" than to have to tunnel arbitrary bytes through some > misleading Unicode encoding. > > While I think it would be generally useful, it's also a long way off at best, > with serious performance dangers that could torpedo the whole thing. But... > I'm also unsure how it would help here, except perhaps we could incrementally > annotate bytes with an encoding? Well, I don't really know. Treating the > raw request path as text is easy enough, as it should always be ASCII > anyway. We don't have to worry what is "right" or "wrong" in this case. > > We could make everything bytes and be done with it, but it would make it much > harder to port Python 2 WSGI code to Python
FWIW, I see the whole ebytes discussion only relevant were you to make absolutely everything bytes. We don't really need it otherwise. Graham _______________________________________________ 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
