[Python-Dev] PEP 414 - Unicode Literals for Python 3

Nick Coghlan ncoghlan at gmail.com
Sun Feb 26 07:06:13 CET 2012


On Sun, Feb 26, 2012 at 1:13 PM, Guido van Rossum <guido at python.org> wrote:
> A small quibble: I'd like to see a benchmark of a 'u' function implemented in C.

Even if it was quite fast, I don't think such a function would bring
the same benefits as restoring support for u'' literals.

Using myself as an example, my work projects (such as PulpDist [1])
are currently written to target Python 2.6, since that's the system
Python on RHEL 6. As a web application, PulpDist has unicode literals
*everywhere*, but (as Armin pointed out to me), turning on "from
__future__ import unicode_literals" in every file would be incorrect,
since many of them also include native strings (mostly related to
attribute names and subprocess invocation, but probably a few WSGI
related ones as well). The action-at-a-distance of that future import
can also make the code hard to read and review (in particular, a diff
doesn't tell you whether or not the future import is present in the
original file).

It's going to be quite some time before I look at porting that code to
Python 3, but, given the style of forward compatible code that I write
(e.g. "print (X)", never "print X" or " print (X, Y)"; "except A as
B:", never "except A, B:"), the lack of unicode literals in 3.x is the
only significant sticking point I expect to encounter. If 3.3+ has
Unicode literals, I expect that PulpDist *right now* would be awfully
close to being source compatible (and any other discrepancies would
just be simple fixes like adding conditional imports from new
locations).

IIRC, I've previously opposed the restoration of unicode literals as a
retrograde step. Looking at the implications for the future migration
of PulpDist has changed my mind.

Regards,
Nick.

[1] https://fedorahosted.org/pulpdist/

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


More information about the Python-Dev mailing list