Graham wrote:
So, rather than throw away completely the idea of bytes everywhere,
and rewrite the WSGI specification, we could instead say that the
existing conceptual idea of WSGI 1.0 is still valid, and just build on
top of it a translation interface to present that as unicode.
I don't think we really need to. Almost nothing in WSGI itself actually
touches Unicode. HTTP headers may in theory be ISO-8859-1 (and certainly
should be handled as such), but in the real world they are exclusively
ASCII (anything else breaks browsers).
SCRIPT_NAME/PATH_INFO is the only part of the spec that potentially
needs more than ASCII, and even then the majority of apps don't put any
Unicode characters in those (especially SCRIPT_NAME). I don't think it's
worth adding the complication of a two-layer interface just for this one
case.
If we can hack around SCRIPT_NAME/PATH_INFO separately as per the other
thread there's no longer any need for anything but ASCII, so WSGI's
strings can be bytes or unicode depending on your taste/Python-version,
without it hurting anyone. The important job of mapping
* query parameters,
* POSTed request bodies, and
* response bodies
between bytes and unicode remains firmly in the application/framework's
area of concern and needs no assistance from WSGI.
--
And Clover
mailto:a...@doxdesk.com
http://www.doxdesk.com/
_______________________________________________
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
