[Python-ideas] A python bridge between versions

[Chris Angelico]

On Fri, Feb 28, 2014 at 5:03 PM, ian o <ian.team.python at gmail.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.

What measures?

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

ChrisA