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

[Chris McDonough]

On Mon, 2012-02-27 at 20:18 +0000, Vinay Sajip wrote:
> 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 great to have software that installs easily.  That said, the
versions of Python that my software supports is (and has to be) be my
choice.

As far as I can tell, there are maybe three or four people (besides me)
using my software on Python 3 right now.  They have it pretty rough:
lackluster library support and they have to constantly mentally
transliterate third-party example code to code that works under Python
3.  They are troopers!

None of them would so much as bat an eyelash if I told them today they
had to use Python 3.3 (if it existed in a final released form anyway) to
use my software.  It's just a minor drop in the bucket of inconvenience
they have to currently withstand.

> > 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?

Like I said in an earlier email, u'' literal support is by no means the
only issue for people who want to straddle.  But it *is* an issue, and
it's incredibly low-hanging fruit with near-zero real-world impact if it
is reintroduced.

> > 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?

You cast it as "backtracking" to reintroduce the syntax, but things have
changed from when the decision to omit it was first made.  Its omission
introduces pain in a world where it's expected that we don't use 2to3 to
automatically translate code at installation time.

> > 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 look at a piece of code as something that exists in one of the
two states "ported" or "not-ported", sure.  But code often needs to be
changed, and people of varying buy-in levels need to understand and
change such code.  It's just much easier for them to assume that the
same syntax works on some versions of Python 2 and Python 3 and be done
with it rather than need to explain the introduction of a function that
only exists to paper over a syntax omission.

> 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
> 
> 
> 
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%40plope.com
>