[Python-Dev] PEP 414 - Unicode Literals for Python 3 (original) (raw)

Chris McDonough chrism at plope.com
Mon Feb 27 22:04:06 CET 2012

On Mon, 2012-02-27 at 20:18 +0000, Vinay Sajip wrote:

Chris McDonough <chrism 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

More information about the Python-Dev mailing list