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