At 02:39 PM 5/8/2009 -0400, James Y Knight wrote:
On May 8, 2009, at 1:37 PM, Robert Brewer wrote:If Python3 WSGI apps emit unicode strings (py3k type 'str'), you're effectively saying the server will always call "chunk.encode('latin-1')". That negates any benefit of using unicode as the type for the response. That's not "supporting unicode"; that's using unicode exactly as if it were an opaque byte string. That's seems silly to me when there is a perfectly useful byte string type.Agreed. Accepting py3k "str" and always encoding in latin-1 is basically just undoing the separation of unicode&byte-strings that was one of Py3k's major design goals. Probably there should be nothing in WSGI should be allowed to be given as either bytestring or character string. The spec should choose one or the other for each circumstance. And for body content it's clear that the only sane thing is a bytestring.
With the amendments as written (and previously discussed here), accepting latin-1 (or ASCII-only) strings allows backward compatibility with code converted via 2to3. Otherwise, you would have to track down every string-returning function in your program that *might* be used to generate a response or a yielded portion thereof.
_______________________________________________ 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
