On 28 February 2014 18:30, Chris Angelico firstname.lastname@example.org wrote:
On Fri, Feb 28, 2014 at 5:03 PM, ian o email@example.com wrote:
Yes it is not easy. Especially if you wish to make use of python2 modules painless.
It's fundamentally not going to be painless. You can either try to move the pain into the thunking module, or keep it in the application, but using a Py2 module is not painless. And I'm not sure it's even possible to move all the pain into the thunker - most Py2 code simply doesn't concern itself with the difference between text and bytes, so there's no automated way to create that difference. (And if the module already does care, then chances are it's easy to port it and officially support Py3, which will be far FAR easier than using the shim - way higher performance too.)
And I agree wholeheartedly that serious thought is needed on the 'could it work so well that it actually slow the migration of library modules?'.
This is an important debate to have. I suggest if the answer to 'can a specification be created that will significantly accelerate migration?', then it is worth the effort to deliver this.
But could it accelerate migration to python 3?
At best, it'll accelerate migration of applications, while slowing migration of libraries.
And we don't actually mind all that much if applications don't migrate in the near term - Python 2 will have commercial support available well past 2020. (The developers of *those applications* might mind, though, just as anyone maintaining Python 2.4 compatibility for the benefit of RHEL/CentOS 5 typically isn't happy about it)
By far the path of least resistance if developers would like to write Python 3 code, but are relying on some legacy Python 2 modules, is to instead write "Python 3 like" code in Python 2. Most of the interesting new Python 3 standard library modules (even asyncio) have Python 2 backports available on PyPI, and python-future (http://python-future.org/index.html) provides backports of the core data types that otherwise don't have Python 2 counterparts.
This isn't *as* nice as actually running under Python 3 (you miss out on exception chaining for one thing, as well as the improvements to error messages in various parts of the standard library, and the infrastructure work that has gone into improving the core interpreter), but it's still a pretty nice environment to work in (heck, Python 2.*6* is still a pretty nice language to work in, although it definitely relies on more external library support than 3.x, or even 2.7).
The group we *do* really care about supporting is authors of existing Python *libraries*, and "2in3" and "3in2" approaches don't really help them at all, since library and framework authors with users on both Python 2 and Python 3 will likely face demand to support both versions natively anyway. That's where various Python 3 changes like restoring Unicode string prefixes, restoring the binary transform codecs, and (for 3.5 in 2015) likely restoring binary interpolation support come in - by making the common subset of Python 2 and Python 3 larger, we make it easier for library authors to support Python 3 without breaking things for their existing Python 2 users.