[Python-Dev] PEP 3333: wsgi_string() function

Ian Bicking ianb at colorstudy.com
Mon Jan 10 18:24:53 CET 2011


On Sun, Jan 9, 2011 at 1:47 AM, Stephen J. Turnbull <stephen at xemacs.org>wrote:

> Robert Brewer writes:
>
>  > Python 3.1 was released June 27th, 2009. We're coming up faster on the
>  > two-year period than we seem to be on a revised WSGI spec. Maybe we
>  > should shoot for a "bytes of a known encoding" type first.
>
> You have one.  It's called "ISO 2022: Information processing -- ISO
> 7-bit and 8-bit coded character sets -- Code extension techniques".
> The popularity of that standard speaks for itself.
>

The kind of object PJE was referring to is more like Ruby's strings, which
do not embed the encoding inside the bytes themselves but have the encoding
as a kind of annotation on the bytes, and do lazy transcoding when combining
strings of different encodings.  The goal with respect to WSGI is that you
could annotate bytes with an encoding but also change or fix that encoding
if other out-of-band information implied that you got the encoding wrong
(e.g., some data is submitted with the encoding of the page the browser was
on, and so nothing inside the request itself will indicate the encoding of
the data).  Latin1 is kind of the poor man's version of this -- it's a good
guess at an encoding, that at worst requires transcoding that can be done in
a predictable way.  (Personally I think Latin1 gets us 99% of the way there,
and so bytes-of-a-known-encoding are not really that important to the WSGI
case.)

  Ian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110110/f5814e1f/attachment.html>


More information about the Python-Dev mailing list