[Python-Dev] readd u'' literal support in 3.3?

[Nick Coghlan]

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" <chrism at 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 <chrism at 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
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20111209/7e60efba/attachment.html>