At 08:42 AM 9/23/2009 +0200, Armin Ronacher wrote:
> I then propose that we eliminate SCRIPT_NAME and PATH_INFO. Instead we
> have:
IMO they should stick around for compatibility with older applications
and be latin1 encoded on Python 3. But the use is discouraged.
One or the other should be there, not both. If you allow older code
to work, this means it could change the old ones but not the new,
leaving a confused mess for child applications to sort out.
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))
When you say "beginning", do you mean the beginning of the return
tuple? That is:
return ['body here'], '200 OK', [('Header', 'value')]
I'd be surprised if a lot of response objects had such a signature,
since that's not the order a server would actually output that data in.
In general I think doing too many changes at once is harmful
Actually, the reverse is true for standards. Incremental change
means more versions, which goes counter to the point of having a
standard in the first place.
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.
The presence of str.decode() should suffice. If you can decode a
string, you're on a Python that has bytes-equivalent strings.
_______________________________________________
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
