On Sep 22, 2009, at 2:28 AM, Armin Ronacher wrote:
Hi,
Alan Kennedy schrieb:
2. Give the programmer (possibly mojibake) unicode strings in the
WSGI
environ anyway
3. And let them solve their problems themselves, using server
configuration or bespoke middleware
Because that problem was solved a long ago in applications themselves.
Webob, Werkzeug, Paste, Pylons, Django, you name it, all are operating
on unicode. And the way they do that is straightforward.
Werkzeug/WebOb/Paste all seem to have standardized on: return unicode,
lazily decoded via a default encoding which can be overridden by the
app via some API.
The Java servlet spec actually defines a
ServletRequest.setCharacterEncoding(String enc) method, which lets the
app override the encoding of the body/params (though not the URL on
some containers), as long it's done before the body is read. Pretty
much what said Python wrappers are doing.
Now currently what we have to do on Python 3 is to encode the data
again
and decode it with the target charset. Unnecessary roundtrips that
just
slow the whole thing down. What for?
Because our request container is a plain, pre-fabricated dict that
doesn't permit the lazy behavior.
--
Philip Jenvey
_______________________________________________
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
