<p>Given that WSGI 1.0.1 is defined in terms of native strings and restoring u'' support allows that to be expressed clearly in a shared codebase, I at least understand the point of the suggestion now. I'm not quite convinced restoring u'' is the right answer as yet, but a solid use case is always a nice place to start :) </p>
<p>--<br>
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, "Chris McDonough" <<a href="mailto:chrism@plope.com">chrism@plope.com</a>> 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>
> On Fri, Dec 9, 2011 at 4:01 PM, Chris McDonough <<a href="mailto:chrism@plope.com">chrism@plope.com</a>> wrote:<br>
> > On the consumer side, folks who want to run 2.6/2.7/3.3-only codebases<br>
> > will have the wherewithal to compile their own Python 3 (or use a PPA or<br>
> > equivalent) until the distros catch up.<br>
> ><br>
> > So I'm not sure why 3.2 not having support for u'' should be a real<br>
> > blocker for the change.<br>
><br>
> If this argument was valid, people wouldn't be so worried about<br>
> maintaining 2.5 compatibility in their libraries. Consider if I tried<br>
> to make this argument to justify everyone dropping 2.5 and earlier<br>
> support today:<br>
><br>
> """On the consumer side, folks who want to run 2.6+ codebases on older<br>
> Linux distros have the wherewithal to compile their own more recent<br>
> Python 2 (or use a PPA or<br>
> equivalent) until they can move to a more recent version of their distro."""<br>
<br>
Fair point.<br>
<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>
<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'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>
<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'm going to be developing software in that subset for many years (way<br>
past the timeframe we're talking about in which Python 3.2 will rule the<br>
roost).<br>
<br>
> It's simply not true in the general case - people don't maintain 2.4+<br>
> compatibility for fun, they do it because RHEL5 (and CentOS 5, etc)<br>
> are still reasonably common and ship with 2.4 as the system Python. As<br>
> soon as you switch away from the system provided Python, you're<br>
> switching away from the vendors entire pre-packaged Python *stack*,<br>
> not just the interpreter itself. You then have to install (and<br>
> generally build) *everything* for yourself. While that is certainly<br>
> possible these days (and a lot simpler than it used to be), it's still<br>
> not trivial [1].<br>
><br>
> Since 3.2 is already quite usable for applications that aren't<br>
> fighting with the "native strings" problem (which seems to be the<br>
> common thread running through the complaints I've heard from web<br>
> framework authors), and with it being included in at least the next<br>
> Ubuntu LTS, current versions of Fedora, Arch, etc, it's going to be<br>
> around for a long time. Ignoring 3.1 is a reasonable option. Ignoring<br>
> 3.2 entirely is unlikely to be viable for anyone that is interested in<br>
> supporting 3.x within the next couple of years - the 3.3 release is at<br>
> least 9 months away, and it's also going to take a while for it to<br>
> make its way into distros after the final release gets published on<br>
> <a href="http://python.org" target="_blank">python.org</a>.<br>
><br>
> Hence my suggestion: perhaps the problem is the fact that PEP 3.3/WSGI<br>
> 1.0.1 introduced the "native string" concept as a minimalist hack to<br>
> try to get a usable gateway interface in Python 3, and that just<br>
> doesn't work in practice when attempting to straddle 2.x and 3.x<br>
> (because the values WSGI is dealing with aren't really text, they're<br>
> bytes, only *some* of which represent text). Perhaps a PEP 444 based<br>
> model would be less painful and more coherent in the long run?<br>
<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>
<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'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>
<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'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>
<br>
Given an effective choice between enabling six lines of code in Python<br>
3.3 to support u'' and months of political wrangling and code rewriting,<br>
I'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'd<br>
be a lot less sanguine about it. But this is just a no-brainer in the<br>
long term, AFAICT.<br>
<br>
- C<br>
<br>
<br>
</blockquote></div>