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

[P.J. Eby]

At 04:50 PM 9/20/2009 +0200, Armin Ronacher wrote:
>Django, Pylons, SQLAlchemy, Mako, Jinja2, Genshi, Werkzeug, WebOb and
>many more technologies are based on unicode, even in Python 2.x.  They
>are currently doing decoding of byte data internally.
>
>In Python 2.x if we stick to native strings for WSGI 2.0 / 1.5 whatever
>we suddenly have different code paths for Python 3 and Python 2.
>Because in Python 3 we suddendly already have unicode data.

No, you'd have bytes stored in a latin-1 string, which is not quite 
the same thing as "already [having] unicode data".  You have to 
.encode('latin1').decode(targetencoding) if you want genuine unicode data.

If you're saying that people's code would have to change when they go 
to Python 3 (i.e., adding the extra .encode()), I think that's 
already a given for *any* non-trivial code, not just WSGI.


> > IMO, this strongly suggests that it's the stdlib or Python 3 that's
> > broken here.  How much of the stdlib are we talking about needing to
> > reimplement, aside from cgi.FieldStorage?
>I'm already creating a patch for urllib which currently requires
>unicode.  I'm not sure about what to do with cgi.FieldStorage, in
>general I would not recommend using the cgi module for WSGI applications
>at all!

But people do, in fact, use it for WSGI on 2.x, so if having 
"different code paths" is a problem, certainly dropping the cgi 
module is at least as big of a problem, if not considerably more so.

I think one of the reasons that the current (and ongoing) PEP 
discussions have been foundering is that there isn't a clear 
delineation of goals at the high level, and rather just a bunch of 
tradeoff discussions, absent any criteria by which to make the tradeoffs.

To me, I'd rather see people port to a new WSGI spec (with a new 
calling convention) on Python 2, and only *then* transition to Python 
3.  If we do that well, then the intermediate pain disappears -- as 
does the pain and complexity of trying to make a bastardized 
in-between specification.  ;-)

Truth be told, we can probably do that new spec *faster* if we don't 
have to worry too much about backward compatibility, and just design 
it for the way things are now, instead of worrying about the 
past.  Even if we have to do some odd things inside a 2-to-1 
converter, there should ideally only have to be a handful of such 
converters ever written.