<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
On 10/01/2011 17:24, Ian Bicking wrote:
<blockquote
cite="mid:AANLkTi=mo4=Si+C88emxejZeOxcThHuRqz5atTEa0Y9b@mail.gmail.com"
type="cite">On Sun, Jan 9, 2011 at 1:47 AM, Stephen J. Turnbull <span
dir="ltr"><<a moz-do-not-send="true"
href="mailto:stephen@xemacs.org">stephen@xemacs.org</a>></span>
wrote:<br>
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt
0.8ex; border-left: 1px solid rgb(204, 204, 204);
padding-left: 1ex;">
<div class="im">Robert Brewer writes:<br>
<br>
> Python 3.1 was released June 27th, 2009. We're coming
up faster on the<br>
> two-year period than we seem to be on a revised WSGI
spec. Maybe we<br>
> should shoot for a "bytes of a known encoding" type
first.<br>
<br>
</div>
You have one. It's called "ISO 2022: Information processing
-- ISO<br>
7-bit and 8-bit coded character sets -- Code extension
techniques".<br>
The popularity of that standard speaks for itself.<br>
</blockquote>
<div><br>
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.)<br>
<br>
</div>
</div>
</blockquote>
<br>
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.<br>
<br>
Michael<br>
<br>
<blockquote
cite="mid:AANLkTi=mo4=Si+C88emxejZeOxcThHuRqz5atTEa0Y9b@mail.gmail.com"
type="cite">
<div class="gmail_quote">
<div> Ian<br>
<br>
</div>
</div>
<pre wrap="">
<fieldset class="mimeAttachmentHeader"></fieldset>
_______________________________________________
Python-Dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Python-Dev@python.org">Python-Dev@python.org</a>
<a class="moz-txt-link-freetext" href="http://mail.python.org/mailman/listinfo/python-dev">http://mail.python.org/mailman/listinfo/python-dev</a>
Unsubscribe: <a class="moz-txt-link-freetext" href="http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk">http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk</a>
</pre>
</blockquote>
<br>
<br>
<pre class="moz-signature" cols="72">--
<a class="moz-txt-link-freetext" href="http://www.voidspace.org.uk/">http://www.voidspace.org.uk/</a>
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 <a class="moz-txt-link-freetext" href="http://www.sqlite.org/different.html">http://www.sqlite.org/different.html</a>
</pre>
</body>
</html>