The afterlife of Python 2

April 30, 2020

Python 2 is officially dead now (cf), with the python.org release of 2.17.18, the last release of Python 2 (also). That means that what happens now is its afterlife, because Python 2 being 'dead' doesn't mean that it's gone, and Python 2 is shaping up to have quite an active and extended afterlife.

Most obviously, various current Unix distributions have versions of Python 2 in them, including the just released Ubuntu 20.04 LTS. This means that Ubuntu will be supporting Python 2 through early 2025 (as much as they support anything, but it probably means making security patches, which can be borrowed by other people). Red Hat is similarly supporting the Python 2 in RHEL 8 until June 2024 (per here). Debian's situation with current and future support of Python 2 is not entirely clear, but my impression of the situation is that on the one hand the Debian Python team wants to drop it but on the other hand other people may step up to support the basic Python 2 interpreter as a Debian package and so keep it available even beyond early 2025.

Beyond that, as pointed out in The final Python 2 release marks the end of an era (via), this is merely the final release of the main CPython implementation of Python 2. PyPy, probably the most major alternate Python implementation, has said that they will be supporting Python 2 for as long as the project exists (also). Since a great deal of the Python standard library is written in Python, it's likely that any security fixes for it that PyPy makes could be readily adopted into CPython (and vice versa, while people continue to support CPython). There's also Tauthon, a fork of CPython 2. I'm not all that interested in its backports of new Python 3 features, which I wrote about back when it was 'Python 2.8', but I'd be perfectly happy to use it as a well supported way to keep having a 'python2' after 2024.

As a practical matter I expect that Python 2 code will be running for at least a decade more in various places, and people will find some way to run it even if it's building Python 2.17.18 from source themselves. Hopefully this will mostly be in places where the security of (C)Python isn't any more relevant than the security properties of a C compiler (or people switch to PyPy), but I'm not counting on that.

(For a start, I wonder how many people are in the same situation with Django applications as we are with ours, where it works fine with Python 2 but lacks the tests and other things necessary to be confident about moving it to Python 3.)

Written on 30 April 2020.
« The problem of Ubuntu 20.04, Snaps, and where your home directory is
What problems Snaps and Flatpaks are solving »

Page tools: View Source, Add Comment.
Search:
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Thu Apr 30 21:08:39 2020
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.