[Python-ideas] A python bridge between versions

[Nick Coghlan]

On 1 March 2014 13:09, ian o <ian.team.python at gmail.com> wrote:
>> 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)
>>
> Your response is most dissapointing, and I would hope does not represent the
> community overall.

My apologies, I wrote my post assuming you had already read
http://docs.python.org/dev/howto/pyporting.html and decided that the
existing approaches described there weren't sufficient for your
purposes. Those cases where the recommended migration process isn't
considered acceptable for some reason (usually non-technical ones) are
the cases that I consider to fall into the "it's OK to just keep using
Python 2" category.

However, I just realised two things:

  * that version of the guide is currently only in the Python 3.4
docs, and so the page at http://docs.python.org/3/howto/pyporting.html
is still displaying the older 3.3 version of the guide (the page in
the Python 2.7 docs is similarly outdated).

  * that guide is currently aimed primarily at library and framework
authors, and doesn't explicitly discuss the migration of integrated
applications.

I have now filed http://bugs.python.org/issue20812 and
http://bugs.python.org/issue20813 to address those limitations, but in
the meantime, I will provide the missing information here:

For developers of integrated applications that currently still have
some dependencies on Python 2, the preferred migration path is to use
tools like python-modernize or python-future to shift first into the
large common subset of Python 2 and Python 3, and then only later
switch fully to Python 3. This approach permits application developers
to take the following path:

1. Python 2 only (status quo)
2. Python 2/3 compatible on Python 2 (waiting for dependencies)
3. Python 2/3 compatible on Python 3 (dependencies ported or replaced)
4. Python 3 only (drop Python 2 support)

Brett Cannon's "caniusepython3" tool
(https://pypi.python.org/pypi/caniusepython3/) is designed to automate
the dependency analysis to see if all declared dependencies are Python
3 compatible (or have suitable alternatives available). However, if
you're using system packages for dependency management, some data
transformations will be needed to convert them to a form that the tool
understands.

My original reply assumed that you were already aware of the details
of this preferred approach before posting your proposal, and I now
realise that assumption was likely incorrect. Once again, my
apologies.

Regards,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia