[Web-SIG] WSGI for Python 3

Ian Bicking ianb at colorstudy.com
Fri Jul 16 19:41:21 CEST 2010


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

-- 
Ian Bicking  |  http://blog.ianbicking.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/web-sig/attachments/20100716/81063afb/attachment-0001.html>


More information about the Web-SIG mailing list