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.
Currently, the python.org website advice on : 'Python2 or Python3 - Which version should I use?' Lists two reasons for using python 2. This 'shim' could eliminate that second very significant reason. Then the advice would be 'if you have a choice of version, use python 3. And I suggest the topic of 'how do I use legacy python2 library modules?', would start by recommending if at all possible, find a python 3 replacement.
Yeah. And if you can't find a Py3 replacement, it might even be worth helping the library to support Py3. If running it through 2to3 does the job, maybe that's all you need to do!
As things stand, the popularity of Python has dropped by most measures since the release of Python 3. Improve the language and lose market share? I suggest that is all about the pain of the transition.
You do not have to search hard to find comments to the effect 'nobody is using python3'. Or 'even if you use python 3, do not use the new features since you need to ensure code is compatible with both versions'.
This is worth careful thought, and again I suggest part of the answer lies in the specification. If the 'do it all' approach to a 'shim' is taken, and using python2 modules is completely painless, no one will ever bother replacing them. Make it too hard to use python2 from python3 and migration is slowed again people do not bother to port libraries because not enough users have yet migrated.
The problem is that there'll still be pain for the application, and there still won't be any for the library. The pain won't move at all. The impetus for a library to support Py3 comes from application developers saying "We need this to support Py3" (and, quite possibly, putting in the work to make it support Py3). Having a fiddly solution will encourage you to make the fiddly one work better, rather than seek the true one.
On python.org survey (2013-2014) , 60% of respondents report that dependencies are keeping them still working on python 2 and 80% are doing more code in python 2.
It's worth noting that that survey asked how many people were using Py2, not about how many weren't using Py3. Lots of people are using both. What that really means, then, is that 20% of those people are adding absolutely no new Py2 code. Quite a lot of those 80% are probably writing 2/3 compatible code.
For most people right now... all the changes and improvements made in python 3 are simply not available and the language is frozen.
Which means the "temptation gap" is getting progressively wider. The temptation to move from 2.4 to 2.6 is "hey look, you get the with statement", the temptation to move from 3.3 to 3.4 is "oh look, enumerations", and so on. The temptation to move to the current version is the sum of all the temptations from your current version onward. Sooner or later, that's going to be a sufficiently-strong incentive that people will just make the jump.
If something like this is done, without making it so painless that there is no incentive to replace or convert dependencies in a new world where the main reason for staying in python 2 has been basically eliminated, then this could be huge benefit.
Just being able to change the python.org web site to say 'use python 3 unless you have no freedom of what version runs on your environment' would be huge!
That's never really going to happen, partly because it's not very helpful :) Unless you're running on a locked-down server that has Py2 installed and no Py3, the problem isn't "no freedom what runs" but "the version suite I want doesn't exist". So the solution is to make what you want exist. In the open source world, there are two ways to do that: lean on the developers, or do the work yourself. (In the closed source world, you lose the second option, but on the flip side, it's that much more likely that your "lean" carries the weight of money.) A number of library/framework maintainers have said that the reason for not supporting Py3 is "lack of interest", which means they quite probably *would* support it if someone expresses enough interest to do the work of porting (or at least help with it); the more applications developers who say "I'd use Py3 except that libspamify.py needs Py2", the more likely that libspamify will sprout Py3 wings.
Binaries of the latest Python 3 are available for most of the popular OSes. I don't keep track of Macs, but on Windows, it's easy to just grab a 3.3 (or, soon, a 3.4), and most Linux distros are carrying at least some form of 3.x (Debian's current stable, Wheezy, ships with 3.2, but Jessie ships with 3.3; RHEL 6 seems to have 3.3, but without having a copy, I can't check authoritatively). So it really is just a matter of library support.