[Python-Dev] PEP 3333: wsgi_string() function
fuzzyman at voidspace.org.uk
Mon Jan 10 18:49:25 CET 2011
On 10/01/2011 17:24, Ian Bicking wrote:
> On Sun, Jan 9, 2011 at 1:47 AM, Stephen J. Turnbull
> <stephen at xemacs.org <mailto: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.)
I think the language moratorium was not the only objection to the
inclusion of a third string type in Python (the "screwed string" - safe
to treat neither as bytes nor as text). I recall objections in principle
too from core developers during the EuroPython language summit.
> Python-Dev mailing list
> Python-Dev at python.org
> Unsubscribe: http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk
May you do good and not evil
May you find forgiveness for yourself and forgive others
May you share freely, never taking more than you give.
-- the sqlite blessing http://www.sqlite.org/different.html
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Python-Dev