I totally agree: The whole HTTP spec has the concept of ASCII implicitly embedded. Converting this to Unicode is, IMHO, the wrong approach. If the spec is talking bytes, then the libraries working with that spec should also be talking bytes.<p>While latin1 can be converted to Unicode, this is not true for all encodings, so the current way how WSGI is handling requests might actually destroy some data in passing (some multibyte japanese encodings cannot be losslessly converted to Unicode).<p>If the library doesn't provide easy methods to do something, it's IMHO totally the wrong approach to potentially destroy data just to have the convenience methods available.<p>So the solution should be to either provide the needed library methods for bytes directly in python or to provide them as a third party library and have WSGI depend on that, though it's probably way easier to just have the internal string methods accept bytes too.
Standard library changes in Python 3 which make supporting WSGI and stacks like it (and protocols in general) more difficult or painful are bugs. Since the stdlib isn't set in stone, those bugs should be fixed by the interested parties.<p>No one involved in core development is infallible, if a decision has been made which is fundamentally flawed, it can and should be changed.