At 11:11 AM 9/15/2010 -0700, Guido van Rossum wrote:
Given that wsgiref is in the stdlib, I think we should hold up the 3.2
release (and even the first beta) until this is resolved, unless we
can convince ourselves that it's okay to delete wsgiref from the
stdlib (which sounds unlikely but may not be any more incompatible
than making it work properly :-).
FWIW, I'd be fine with that option.
I want to emphasize that I am *not* a stakeholder so my preference for
bytes or Unicode shouldn't matter; that said, given WSGI's traditional
emphasis on using the lowest-level, vanilla standard datatypes (e.g.
you can't even subclass dict let alone provide another kind of mapping
-- it has to be a real dict) it makes sense to me that the values
should be bytes, os.environ notwithstanding. The keys probably could
be Unicode (HTTP headers are required to use only 7-bit ASCII
characters anyways right?). But I'd be happy to be shown the error of
my ways (or given a link showing prior discussion of the matter --
preferably with a conclusion :-).
There isn't a conclusion yet, but the proposals under discussion are
summarized here:
http://www.wsgi.org/wsgi/Python_3#Proposals
The primary points of consensus are bytes for wsgi.input, and native
strings (i.e. Unicode on Python 3) for environment keys.
If I were to offer a suggestion to a PEP author or dictator wanting
to get something out ASAP, it would probably be to create a
compromise between the "flat" model (my personal favorite) and the
mod_wsgi model, as an addendum to PEP 333. Specifically:
* leave start_response/write in play (ala mod_wsgi)
* use the required types from the "flat" proposal (i.e. status,
headers, and output stream MUST be bytes)
* add a decorator to wsgiref that supports using native strings as
output instead of bytes, for ease-of-porting (combine mod_wsgi's
ease-of-porting w/"flat"'s simple verifiability)
This would probably allow us to get by with the least changes to
existing code, the stdlib, the standard itself, and
wsgiref. (wsgiref itself would still need a thorough code review,
especially wsgiref.validate, but it'd be unlikely to change much.)
_______________________________________________
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
