[Python-Dev] 3.x as the official release

[P.J. Eby]

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.)