Author pje
Recipients hdima, pitrou, pje
Date 2008-12-23.16:08:04
SpamBayes Score 3.40214e-05
Marked as misclassified No
Message-id <20081223160802.7D8653A409D@sparrow.telecommunity.com>
In-reply-to <1230042406.12104.61.camel@localhost>
Content
Antoine, you have three choices here:

1. Follow the PEP,
2. Take it to the Web-SIG and get the appropriate discussion, 
consensus, and PEP revision, or
3. Drop wsgiref from the current release of Py3K until #2 can be done.

Which would you prefer?

Please note that your arguments regarding what revision should take 
place are irrelevant here; the correct forum for that discussion is 
the Web-SIG.  Personally, I think they are valid arguments; WSGI 
simply did not have the benefit of having a sane (and standard!) 
"bytes" type available, and were we writing the spec today, I would 
absolutely have specified it in a bytes-oriented way, and treated 
older Pythons as the special case.

However, we have to take into consideration how applications will be 
*migrated* to Py3K.  I am not an expert in this, nor do I personally 
have huge volumes of code that will be migrated.  Therefore, the 
correct forum for discussing migration impact and how best to write 
the spec is the Web-SIG.

Making the change to bytes is not something to be undertaken on a 
whim: the spec must include how to handle inadvertent mixing of bytes 
and unicode, in order to allow unambiguous error handling and 
migration support.  It will not be solved by the fiat of one 
individual: certainly not by you or I.  And it has absolutely nothing 
to do with what is "right" in the technical sense, because it is not 
a technical problem.  A specification is a social construct, not a 
technical one, so changing wsgiref by itself solves nothing.

And that's why those three choices are the only available options, so 
far as I am aware.
History
Date User Action Args
2008-12-23 16:08:06pjesetrecipients: + pje, hdima, pitrou
2008-12-23 16:08:05pjelinkissue4718 messages
2008-12-23 16:08:05pjecreate