[Python-Dev] 3.x as the official release
pje at telecommunity.com
Wed Sep 15 21:18:14 CEST 2010
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
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.)
More information about the Python-Dev