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