Phillip J. Eby wrote: > At 04:54 PM 3/25/2008 +1100, Graham Dumpleton wrote: >> Why are servers and gateways being made to accept strings when the >> preference is for applications to produce bytes for both? Is this >> acknowledgment that getting people to convert WSGI applications to >> produce bytes may be a problem? > > Yep. > >> The text of (2) sorts of suggests there is justification for this in >> saying 'under the existing rules (i.e., s.encode('latin-1') must >> convert the string to bytes without an exception', but I can't find >> such a rule in the WSGI PEP when I have a quick look. In other words, >> where in the existing specification does it say that Unicode strings >> must be accepted, to the contrary it suggests they can't be and that >> using them where a string object is expected is undefined. > > It says that in versions of Python where 'str is unicode' (i.e. > Jython, IronPython, and Python 3000), then the specification should > be read to define "string" as a unicode string whose characters can > be expressed in latin-1. > > Really, adding support for bytes is the stretch here. In fact, I'd > almost go so far as to say the heck with bytes support except for the > response body. I could easily consider headers to be text, instead.
Latin-1? How is this supposed to work at all? For instance, we treat SCRIPT_NAME/PATH_INFO as UTF8 encoded strings. (QUERY_STRING isn't really UTF8 until you url-decode it, but SCRIPT_NAME and PATH_INFO are already decoded) While there are certain HTTP headers where Latin-1 is a reasonable assumption, as it has been encoded into various specs, I don't generally see the purpose. Any application that can only speak Latin-1 is broken. Am I missing something here? I would prefer using bytes most places in WSGI where str is currently used. Ian _______________________________________________ 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