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

[Chris McDonough]

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
>