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

Vinay Sajip vinay_sajip at yahoo.co.uk
Mon Feb 27 21:18:31 CET 2012


Chris McDonough <chrism <at> plope.com> writes:

> I suspect not everyone lives and dies by OS distribution release support
> policies.  Many folks are both willing and capable to install a newer
> Python on an older OS.

But many folks aren't, and lament the slow pace of Python version adoption on
e.g. Red Hat and CentOS.

> It's unfortunate that Python 3 < 3.3 does not have the syntax, and
> people like me who have a long-term need to "straddle" are to blame; we
> didn't provide useful feedback early enough to avoid the mistake.  That
> said, it seems like preventing a reintroduction of u'' literal syntax
> would presume that two wrongs make a right.  By our own schedule
> estimate of Python 3 takeup, many people won't be even thinking about
> porting any Python 2 code to 3 until years from now.

If the lack of u'' literal is what's holding them back, that's germane to the
discussion of the PEP. If it's not, then why propose the PEP?

> An argument for the reintroduction of u'' literal syntax in Python >=
> 3.3 is not necessarily an argument against the utility of some automated
> tool conversion support for porting a Python 2 app to a function-based
> u() syntax so it can run in Python 3 < 3.2.

I thought the argument was more about backtracking (or not) from Python 3's
design decision to use 'xxx' for text and b'yyy' for bytes. That's the only
"wrong" we're talking about for this PEP, right?


> Currently we handle 3.2 compatibility in packages that "straddle" via
> six-like functions.  We can continue doing this as necessary.  If the
> stdlib tooling helps, great.  In an emit-function-based-syntax mode, the
> conversion code would almost certainly need to rely on the import of an
> externally downloadable module like six, for compatibility under both
> Python 2 and 3 because there's no opportunity to go back in time and
> make "u()" available for older releases unless it was like inlined in
> every module during the conversion.
> 
> But if somebody only wants to target 3.3+, and it means they don't have
> to rely on a six-like module to provide u(), great.

If you only need to straddle from 2.6 onwards, then u('') isn't an issue at all,
right now, is it?

If you need to straddle from 2.5 downwards, there are other issues to be
addressed, like exception syntax, 'with' and so forth - so making u'' available
doesn't make the port a no-brainer. And if you bite the bullet and decide to do
the port anyway, converting u'' to u('') won't be a problem unless you (a) can't
use a fixer to automate the conversion or (b) the function call overhead cannot
be borne. I'm not sure either of those objections (can't use fixer, call
overhead excessive) have been made with sufficient force (i.e., data) in the
discussion so far.

Regards,

Vinay Sajip





More information about the Python-Dev mailing list