This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author pitrou
Recipients hdima, pitrou, pje
Date 2008-12-23.14:26:48
SpamBayes Score 7.034594e-06
Marked as misclassified No
Message-id <1230042406.12104.61.camel@localhost>
In-reply-to <4950F0A8.2010304@hlabs.spb.ru>
Content
> No, just as PEP said str used as a container for binary data.

This is clearly the wrong thing to do. The only (immutable) string-like
object adequate for binary data in py3k is bytes, not str.

I understand the desire to stick to the PEP, but the PEP was devised
even before the first py3k alphas, and it clearly wasn't written with
py3k in mind. For example the following sentence becomes nonsensical:

        Again, all strings referred to in this specification must be of
        type str or StringType, and must not be of type unicode or
        UnicodeType.

since "str" objects *are* of type UnicodeType in py3k (and the C API is
still named PyUnicode_*)...

When a legal text becomes nonsensical wrt. reality, one has to adapt his
interpretation of the text to reality, not adapt reality to match the
nonsense.

In other words, wsgiref should accept/expose HTTP bodies as bytes, not
str. Confusing binary data with iso-8859-1 text is the kind of mess py3k
was designed to avoid.
History
Date User Action Args
2008-12-23 14:26:52pitrousetrecipients: + pitrou, pje, hdima
2008-12-23 14:26:49pitroulinkissue4718 messages
2008-12-23 14:26:48pitroucreate