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

[Nick Coghlan]

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."""

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?

Cheers,
Nick.

[1] http://readthedocs.org/docs/ncoghlan_devs-python-notes/en/latest/venv_bootstrap.html

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia