Hi,
On 2010-08-27 5:45 AM, P.J. Eby wrote:
> At 01:37 AM 8/27/2010 +0200, Armin Ronacher wrote:
> To the extent we're "unsure", I think the holdup is simply that nobody
> has tried doing an all-bytes WSGI implementation -- unless of course you
> count all our Python 2.x experience as experience with an all-bytes
> implementation. ;-)
I have a private branch of Werkzeug that is all bytes only. Untested
unfortunately because porting the testsuite over is a huge task on its
own and not all parts work properly yet. But it's okayish.
Werkzeug does not use anything from the standard library in the latest
version except urljoin from the url parse package which I would have to
rewrite for my little experiment. In my attempt to port it I'm doing
the encode/decode dance in a wrapper function.
> In theory, if we did it correctly it could actually minimize the porting
> pain for Python 3.
>
> In practice, I'm not sure how to do this, as I lack experience with 2to3
> at the moment, or any production experience with Python 3 whatsoever.
The big problem for me is that we *will* have to run to 2to3 because
WSGI sometimes leaks from the framework to the application. This is
especially true for Django where request.META is directly passed as WSGI
environment to the user and no accessor functions exist. So everybody
and is parsing the headers themselves there.
So when frameworks are starting to support any version of WSGI on Python
3 they will also have to ship custom 2to3 fixers that add tiny shims for
decoding/encoding either side of comparisons etc.
For example it's pretty common to see stuff like this:
if 'msie' in request.META.get('HTTP_USER_AGENT', '').lower():
For an all bytes approach a tool would have to recognize that this is
from a WSGI environment and change the code to this:
if b'msie' in request.META.get('HTTP_USER_AGENT', b'').lower():
That's not impossible to do and in my mind the right decision, but it
also means extra work to be done. And if extra work is required when
porting a framework and application over to Python 3 we could reward the
people doing that with improvements of the specification itself.
I'm thinking about improving file_wrapper (so that middlewares can
either detect that a file_wrapper is here and they should not consume
the app iter, or just replacing it with a custom header), the input
stream etc.
Regards,
Armin
_______________________________________________
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
