At 05:42 PM 7/16/2010 -0400, Tres Seaver wrote:
P.J. Eby wrote:
> (Hm. Although actually, I suppose we *could* just borrow the time
> machine and pretend that WSGI called for "byte-strings everywhere"
> all along...)
I like the idea of pushing responsibility for decoding stuff into the
framework / app writer's hands. OTOH, doesn't that hose authors of
existing middleware, due to the borkedness of working with bytes in Python3?
It only creates a "new" problem if they are currently not using *any*
unicode in 2.x, and are passing through bytes from the input to the
output without any encoding or decoding. AFAICT, if any part of
their app is currently unicode, they would have the same problems in 2.x.
(Minus, of course, any problems introduced by missing bytes methods
in 3.x, or the fact that single-subscripted bytes are ints rather
than bytestrings.)
Anyway, the problems introduced will be problems that can be solved
by waving a fairly standard set of dead chickens at the problem, i.e.
picking where you're going to encode/decode, and deciding what
encoding(s) are meaningful to your app. And frameworks that already
have a unicode API are ahead of the game here.
So, AFAICT, the only people who'd be punished by a change to bytes
are the people who have non-ASCII inputs or outputs, but haven't been
using unicode (because 2to3 will convert them to using strings
instead of bytes).
From what I can tell, though, this is also the group it's most
politically correct to hate on in Python-Dev, so we should be
relatively safe in shifting the burden to them. ;-)
_______________________________________________
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
