[Web-SIG] Request for Comments on upcoming WSGI Changes

[Massimo Di Pierro]

+1

On Sep 20, 2009, at 11:25 PM, Chris McDonough wrote:

> I'll try to digest some of this, currently I'm pretty clueless.
>
> Personally, I find it a bit hard to get excited about Python 3 as a  
> web
> application deployment platform.  This is of course a personal  
> judgment (I
> don't mean to slight Python 3) but at this point, I'll think I'll  
> probably be
> writing software that targets 2.X exclusively for at least the next  
> five years.
>
> Given this point of view, it would be extremely helpful if someone  
> could
> explain to people with the same outlook why we should want to deal  
> with Unicode
> strings in any WSGI specification.
>
> WSGI is a fairly low-level protocol aimed at folks who need to  
> interface a
> server to the outside world.  The outside world (by its nature)  
> talks bytes.  I
> fear that any implied conversion of environment values and iterable  
> return
> values to Unicode will actually eventually make things harder than  
> they are
> now.  I realize that it would make middleware implementors lives  
> harder to need
> to deal in bytes.  However, at this point, I also believe that  
> middleware kinda
> should be hard.  We have way too much middleware that shouldn't be  
> middleware
> these days (some written by myself).
>
> Anyway, for us slower (and maybe wrongly fearful) folks, could someone
> summarize the benefits of having a WSGI specification that requires  
> Unicode.
> Bonus points for an explanation that does not boil down to "it will be
> compatible with Python 3".
>
> - C
>
>
> Armin Ronacher wrote:
>> Hello everybody,
>>
>> Thanks to Graham Dumpleton and Robert Brewer there is some serious
>> progress on WSGI currently.  I proposed a roadmap with some PEP  
>> changes
>> now that need some input.
>>
>> Summary:
>>
>>  WSGI 1.0       stays the same as PEP 0333 currently is
>>  WSGI 1.1       becomes what Ian and I added to PEP 0333
>>  WSGI 2.0       becomes a unicode powered version of WSGI 1.1
>>  WSGI 3.0       becomes WSGI 2.0 just without start_response
>>
>>  WSGI 1.0 and 1.1 are byte based and nearly impossible to use on  
>> Python
>>  3 because of changes in the standard library that no longer work  
>> with
>>  a byte-only approach.
>>
>>
>> The PEPs themselves are here: http://bitbucket.org/ianb/wsgi-peps/
>> Neither the wording not the changes in there are anywhere near final.
>>
>>
>> Graham wrote down two questions he wants every major framework  
>> developer
>> to be answered.  These should guide the way to new WSGI standards:
>>
>> 1. Do we keep bytes everywhere forever in Python 2.X, or try to
>>   introduce unicode there at all to at least mirror what changes  
>> might
>>   be made to make WSGI workable in Python 3.X?
>>
>> 2. Do we skip WSGI 1.X completely for Python 3.X and go straight to
>>   WSGI 2.0 for Python 3.X?
>>
>> I added a new question I think should be asked too:
>>
>> 3. Do we skip WSGI 2.0 as specified in the PEP and go straight to
>>   WSGI 3.0 and drop start_response?
>>
>>
>> The following things became pretty clear when playing around with
>> various specifications on Python 3:
>>
>> -  Python 3 no longer implicitly converts between unicode and byte
>>   strings.  This covers comparisons, the regular expression engine,
>>   all string functions and many modules in the stdlib.
>>
>> -  The Python 3 stdlib radically moved to unicode for non unicode  
>> things
>>   as well (the http servers, http clients, url handling etc.)
>>
>> -  A byte only version of WSGI appears unrealistic on Python 3  
>> because
>>   it would require server and middleware implementors to reimplement
>>   parts of the standard library to work on bytes again.
>>
>> -  unicode support can be added for WSGI on both Python 2.x and  
>> Python
>>   3.x without removing functionality.  Browsers are already doing
>>   a similar encoding trick as proposed by Graham Dumpleton to handle
>>   URLs.
>>
>> -  Python 2.x already accepts unicode strings for many things such as
>>   URL handling thanks to the fact that unicode and byte strings are
>>   surprisingly interchangeable.
>>
>> -  cgi.FieldStorage and some other parts is now totally broken on
>>   Python 3 and should no longer be used in 3.0 and 3.1 because it
>>   reads the response body into memory.  This currently affects
>>   WebOb, Pylons and TurboGears.
>>
>>
>> I sent this mail to every major framework / WSGI implementor so  
>> that we
>> get input even if you're missing the discussion on web-sig.
>>
>>
>> Regards,
>> Armin
>> _______________________________________________
>> Web-SIG mailing list
>> Web-SIG at python.org
>> Web SIG: http://www.python.org/sigs/web-sig
>> Unsubscribe: http://mail.python.org/mailman/options/web-sig/chrism%40plope.com
>>
>
> _______________________________________________
> Web-SIG mailing list
> Web-SIG at python.org
> Web SIG: http://www.python.org/sigs/web-sig
> Unsubscribe: http://mail.python.org/mailman/options/web-sig/mdipierro%40cs.depaul.edu