<p>Given that WSGI 1.0.1 is defined in terms of native strings and restoring u&#39;&#39; support allows that to be expressed clearly in a shared codebase, I at least understand the point of the suggestion now. I&#39;m not quite convinced restoring u&#39;&#39; is the right answer as yet, but a solid use case is always a nice place to start :) </p>

Nick Coghlan (via Gmail on Android, so likely to be more terse than usual)</p>
<div class="gmail_quote">On Dec 9, 2011 5:38 PM, &quot;Chris McDonough&quot; &lt;<a href="mailto:chrism@plope.com">chrism@plope.com</a>&gt; wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Fri, 2011-12-09 at 16:36 +1000, Nick Coghlan wrote:<br>
&gt; On Fri, Dec 9, 2011 at 4:01 PM, Chris McDonough &lt;<a href="mailto:chrism@plope.com">chrism@plope.com</a>&gt; wrote:<br>
&gt; &gt; On the consumer side, folks who want to run 2.6/2.7/3.3-only codebases<br>
&gt; &gt; will have the wherewithal to compile their own Python 3 (or use a PPA or<br>
&gt; &gt; equivalent) until the distros catch up.<br>
&gt; &gt;<br>
&gt; &gt; So I&#39;m not sure why 3.2 not having support for u&#39;&#39; should be a real<br>
&gt; &gt; blocker for the change.<br>
&gt; If this argument was valid, people wouldn&#39;t be so worried about<br>
&gt; maintaining 2.5 compatibility in their libraries. Consider if I tried<br>
&gt; to make this argument to justify everyone dropping 2.5 and earlier<br>
&gt; support today:<br>
&gt; &quot;&quot;&quot;On the consumer side, folks who want to run 2.6+ codebases on older<br>
&gt; Linux distros have the wherewithal to compile their own more recent<br>
&gt; Python 2 (or use a PPA or<br>
&gt; equivalent) until they can move to a more recent version of their distro.&quot;&quot;&quot;<br>
Fair point.<br>
That said, personally, I have given up entirely on Python 2.4 and 2.5<br>
support for newer versions of my OSS libraries.  I continue to backport<br>
fixes and (some) features to older library versions so folks can run<br>
those on systems that require older Pythons.  I gave up 2.5 support<br>
fairly recently across everything new, and I gave up support for 2.4 a<br>
year ago or more in new releases with the same intent.<br>
In reality, there is only one major platform that requires 2.4: RHEL 5<br>
and folks who use it will just need to also use old versions of popular<br>
libraries; trying to support it for all future feature work until it&#39;s<br>
EOLed is not sane unless someone pays for it.  Python 2.5 has slightly<br>
more compelling platforms (GAE and Jython), but GAE is moving to Python<br>
2.7 and Jython is a bit moribund these days and is not really popular<br>
enough that a critical mass of folks will clamor for new-and-shiny<br>
releases that run on it.<br>
The upshot is that most newly created code only needs to run on Python<br>
2.6 and *some* version of Python 3.  And being able to eventually write<br>
that code in a nonsucky subset of Python 2/3 is important to me, because<br>
I&#39;m going to be developing software in that subset for many years (way<br>
past the timeframe we&#39;re talking about in which Python 3.2 will rule the<br>
&gt; It&#39;s simply not true in the general case - people don&#39;t maintain 2.4+<br>
&gt; compatibility for fun, they do it because RHEL5 (and CentOS 5, etc)<br>
&gt; are still reasonably common and ship with 2.4 as the system Python. As<br>
&gt; soon as you switch away from the system provided Python, you&#39;re<br>
&gt; switching away from the vendors entire pre-packaged Python *stack*,<br>
&gt; not just the interpreter itself. You then have to install (and<br>
&gt; generally build) *everything* for yourself. While that is certainly<br>
&gt; possible these days (and a lot simpler than it used to be), it&#39;s still<br>
&gt; not trivial [1].<br>
&gt; Since 3.2 is already quite usable for applications that aren&#39;t<br>
&gt; fighting with the &quot;native strings&quot; problem (which seems to be the<br>
&gt; common thread running through the complaints I&#39;ve heard from web<br>
&gt; framework authors), and with it being included in at least the next<br>
&gt; Ubuntu LTS, current versions of Fedora, Arch, etc, it&#39;s going to be<br>
&gt; around for a long time. Ignoring 3.1 is a reasonable option. Ignoring<br>
&gt; 3.2 entirely is unlikely to be viable for anyone that is interested in<br>
&gt; supporting 3.x within the next couple of years - the 3.3 release is at<br>
&gt; least 9 months away, and it&#39;s also going to take a while for it to<br>
&gt; make its way into distros after the final release gets published on<br>
&gt; <a href="http://python.org" target="_blank">python.org</a>.<br>
&gt; Hence my suggestion: perhaps the problem is the fact that PEP 3.3/WSGI<br>
&gt; 1.0.1 introduced the &quot;native string&quot; concept as a minimalist hack to<br>
&gt; try to get a usable gateway interface in Python 3, and that just<br>
&gt; doesn&#39;t work in practice when attempting to straddle 2.x and 3.x<br>
&gt; (because the values WSGI is dealing with aren&#39;t really text, they&#39;re<br>
&gt; bytes, only *some* of which represent text). Perhaps a PEP 444 based<br>
&gt; model would be less painful and more coherent in the long run?<br>
Possibly.  I was the original author of PEP 444 with help from Armin.<br>
(although it has since been taken up by Alice and I do not support the<br>
updates it has received since then).<br>
A bytes-oriented WSGI-like protocol was always the saner option.  The<br>
native string idea optimized in exactly the wrong place, which was to<br>
make it easy to write WSGI middleware, where you&#39;re required to do lots<br>
of textlike manipulation of header values.  The idea of using bytes in<br>
places where PEP 3333 now mandates native strings was rejected because<br>
people were (somewhat justifiably) horrified at what they had to do in<br>
order to attempt treat bytes like strings in this context on Python 3 at<br>
the time.  It has gotten better, but maybe still not better enough to<br>
appease the folks who blocked the idea originally.<br>
But all of that is just arguing with the umpire at this point.<br>
Promoting and getting consensus about a different protocol will hurt a<br>
lot.  PEP 3333 was borne of months of intense periods of arguing and<br>
compromise.  It is the way it is now because everyone was too exhausted<br>
to argue about it any more.  I don&#39;t think that has changed much since<br>
it was accepted, and asking folks to go back to that particular drawing<br>
board is unlikely to have promising results.  Folks have already spent<br>
many hours, and lots of money on implementations that the current PEP.<br>
They may hunt us down and murder us one by one. ;-)  PEP 3333, to its<br>
credit, is also remarkably backwards compatible with PEP 333, requiring<br>
very little change in existing Python 2 WSGI implementations, which<br>
helps Python 2 folks a lot.<br>
Given an effective choice between enabling six lines of code in Python<br>
3.3 to support u&#39;&#39; and months of political wrangling and code rewriting,<br>
I&#39;ll choose the former any day.  If we were talking about a change to<br>
Python that actually required nontrivial effort, had some sort of<br>
nominal consequence, or had some sort of non-theoretical downside, I&#39;d<br>
be a lot less sanguine about it.  But this is just a no-brainer in the<br>
long term, AFAICT.<br>
- C<br>