[Web-SIG] WSGI for Python 3

[Armin Ronacher]

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