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.
_______________________________________________
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
