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

[Chris McDonough]

On Mon, 2012-02-27 at 13:44 -0500, Terry Reedy wrote:
> On 2/27/2012 1:01 PM, Chris McDonough wrote:
> > On Mon, 2012-02-27 at 12:41 -0500, R. David Murray wrote:
> >> Eh?  The 2.6 version would also be u('that').  That's the whole point
> >> of the idiom.  You'll need a better counter argument than that.
> >
> > The best argument is that there already exists tons and tons of Python 2
> > code that already does:
> >
> >    u'that'
> >
> > Needing to change it to:
> >
> >    u('that')
> >
> > 1) Requires effort on the part of a from-Python-2-porter to service
> >     the aesthetic and populist goal of not having an explicit
> >     but redundant-under-Py3 literal syntax that says "this is text".
> 
> This is a point, though this would be a one-time conversion by a 2to23 
> converter that would be part of other needed conversions, some by hand. 
> I presume that most 2.6 code has problems other than u'' when attempting 
> to run under 3.x.
> 
> > 2) Won't atually meet the aesthetic goal, as
> >     it's uglier and slower under *both* Python 2 and Python 3.
> 
> Less relevant. The minor ugliness would be in dual-version code, but not 
> Python 3 itself.
> 
> > So the populist argument remains.. "it's too confusing for people who
> > learn Python 3 as a new language to have a redundant syntax".  But we've
> > had such a syntax in Python 2 for years with b'', and, as mentioned by
> > Armin's PEP single-quoted vs. triple-quoted strings forever.
> >
> > I just don't understand the pushback here at all.
> 
> For one thing, u'' does not solve the problem for 3.1 and 3.2, while u() 
> does. 3.2 will be around for years. For one example, it will be in the 
> April long-term-support release of Ubuntu. For another, PyPy is working 
> on a 3.2 compatible version to come out and be put into use this year.

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.

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.

>  > This is such a nobrainer.
> 
> I could claim that a solution that also works for 3.1 and 3.2 is a 
> nobrainer. It depends on how one weighs different factors.

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.

Tools like "2to23" or whatever can obviously be parameterized to emit
slightly different 3.2-compatible and 3.3-compatible code.  It's almost
certain that it will need forward-version-aware modes like this anyway
as newer idioms are added to 3.X that make code prettier or more
efficient completely independent of u'' support.

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.

- C