At 04:00 PM 1/6/2011 -0800, Raymond Hettinger wrote:
Can you please take a look at
<http://docs.python.org/dev/whatsnew/3.2.html#pep-3333-python-web-server-gateway-interface-v1-0-1>http://docs.python.org/dev/whatsnew/3.2.html#pep-3333-python-web-server-gateway-interface-v1-0-1
to see if it accurately recaps the resolution of the WSGI text/bytes issues.
I would appreciate any feedback, as it is likely that the whatsnew
document will be most people's first chance to hear the outcome
of the multi-year discussion.
Hi Raymond -- nice work there. A few minor suggestions:
1. Native strings are used as the keys and values of the environ
dictionary, not just as headers for start_response.
2. The read_environ() method is strictly for use with CGI-to-WSGI
gateways, or for bridging other CGI-like protocols (e.g. FastCGI) to
WSGI. It is ONLY for server implementers, in other words, and the
typical app developer is doing something terribly wrong if they are
even bothering to read its documentation. ;-)
3. The primary relevance of the "native string" type to an app
developer is that when porting code from Python 2 to 3, they must
still decode environment variable values, even though they are
"already" Unicode. If their code was previously dealing only in
Python 2 'str' objects, then nothing really changes. If they were
previously decoding from environ str's to unicode, then they must
replace their prior .decode('whatever') with
.encode('latin1').decode('whatever'). That's basically it for
porting from Python 2.
IOW, this design choice allows most HTTP header manipulating code
(whether input or output) to be ported to Python 3 with a very
mechanical change pattern. Most such code is working with ASCII
anyway, since normally both input and output headers are, and there
are few headers that an application would be likely to convert to
actual unicode anyway.
On output via send_response(), if an application is currently
encoding an output header -- why they would be, I have no idea, but
if they are -- they need to add a re-encode to latin1. (i.e.,
.encode('whatever').decode('latin1'))
IOW, a short 2-to-3 porting guide for WSGI:
* If you just used strings for headers before, that part of your code
doesn't change. (And if it was broken before, it's still broken in
exactly the same way. No new breakage is introduced. ;-) )
* If you encoded any output headers or decoded any input headers, you
must take into account the extra latin1 step. This is expected to be
rare, since it's usually only SCRIPT_NAME and PATH_INFO that anybody
would ever care about on input, and almost never anything on output.
* Values yielded by an application or sent via a write() call MUST be
byte strings; The environ and start_response() MUST be native
strings. No mixing and matching.
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
