[Web-SIG] Proposal to remove SCRIPT_NAME/PATH_INFO
armin.ronacher at active-4.com
Wed Sep 23 08:42:26 CEST 2009
Ian Bicking schrieb:
> I propose we switch primarily to "native" strings: str on both Python 2 and
I'm starting to think that this is the best idea.
> I then propose that we eliminate SCRIPT_NAME and PATH_INFO. Instead we
IMO they should stick around for compatibility with older applications
and be latin1 encoded on Python 3. But the use is discouraged.
> Again, it would be better to do;
That will only work in Python 2, in Python 2 urllib.unquote already
yields unicode strings and assumes an utf-8 quoted string.
> Other variables like environ['wsgi.url_scheme'], environ['CONTENT_TYPE'],
> etc, will be native strings. A Python 3 hello work app will then look like:
> def hello_world(environ):
> return ('200 OK', [('Content-type', 'text/html; charset=utf8')], ['Hello
> start_response and changes to wsgi.input are incidental to what I'm
> proposing here (except that wsgi.input will be bytes); we can decide about
If we go about dropping start_response, can we move the app iter to the
beginning? That would be consistent with the signature of common
response objects, making it possible to do this:
response = Response(*hello_world(environ))
In general I think doing too many changes at once is harmful so I'm
happy to stick with start_response for another iteration of WSGI.
> Well, the biggie: is it right to use native strings for the environ values,
> and response status/headers? Specifically, tricks like the latin1
> transcoding won't work in Python 2, but will in Python 3. Is this weird?
> Or just something you have to think about when using the two Python
The WSGI PEP should standardize a way for the application to figure out
the environment it runs in. And that I think that should *not* be
checking sys.version_info but rather comparing string features.
> What happens if you give unicode text in the response headers that cannot be
> encoded as Latin1?
Undefined behavior, the example server should raise an assertion error.
> Should some things specifically be ASCII? E.g., status.
No, HTTP specifies the status as TEXT and TEXT is specified as (any
8-bit sequence of data except any US-ASCII control character but
including CR, LR, space and tabs).
> Should some things be unicode on Python 2?
I don't think so.
> Is there a common case here that would be inefficient?
Don't think so.
More information about the Web-SIG