[Web-SIG] WSGI for Python 3
graham.dumpleton at gmail.com
Sat Jul 17 07:55:23 CEST 2010
On Saturday, July 17, 2010, Ian Bicking <ianb at colorstudy.com> wrote:
> On Fri, Jul 16, 2010 at 12:28 PM, Chris McDonough <chrism at plope.com> wrote:
> On Fri, 2010-07-16 at 11:07 -0500, Ian Bicking wrote:
>> And this doesn't help with Python 3: either we have byte values of
>> SCRIPT_NAME and PATH_INFO in Python 3, or we have text values. I
>> think bytes will be more awkward to port to than text, and
>> inconsistent with other WSGI values. If we have text then we have to
>> choose an encoding. Latin1 will work, but it will be the exact wrong
>> encoding most of the time as UTF-8 is the typical (unlike other
>> headers, where Latin1 will mostly be an okay encoding, or as good a
>> guess as we have). If we firmly remove these keys then we can avoid
>> this choice entirely... and we conveniently also get a better
>> representation of the request.
> My $.02: I'd rather lobby the core folks for a string ABC (which we can
> hook with a stringlike bytes type) and consider all 3.X releases made so
> far "dead to WSGI" than to have to tunnel arbitrary bytes through some
> misleading Unicode encoding.
> While I think it would be generally useful, it's also a long way off at best, with serious performance dangers that could torpedo the whole thing. But... I'm also unsure how it would help here, except perhaps we could incrementally annotate bytes with an encoding? Well, I don't really know. Treating the raw request path as text is easy enough, as it should always be ASCII anyway. We don't have to worry what is "right" or "wrong" in this case.
> We could make everything bytes and be done with it, but it would make it much harder to port Python 2 WSGI code to Python
FWIW, I see the whole ebytes discussion only relevant were you to make
absolutely everything bytes. We don't really need it otherwise.
More information about the Web-SIG