Title: When Will Python 2 End?

Author: Bob Schmidt

Date: 08 January 2019 16:22:34 +00:00 or Tue, 08 January 2019 16:22:34 +00:00

Summary: Silas Brown explains why the days of Python 2, while numbered, may be longer than you think.

Body: 

The last major release of Python 2 (i.e. Python 2.7) has been with us since 2010, and since then it has been a considerably stable language—more so than Python 3—so I have preferred Python 2 for production use, and not just because I occasionally want to run code on an old device for which there does not exist a Python 3 runtime (although there’s that as well).

As Python includes rather a lot of libraries that you might be using to handle untrusted data (such as data you receive from the Internet), it would be good if any security issues yet to be discovered in the runtime or libraries are fixed when they are found, before the associated exploit code ends up in ‘script kiddie’ arsenal. While it seems increasingly unlikely that a stable library that has been in the public eye for years with no new features added would still have undiscovered security bugs of any serious consequence, it would certainly be more reassuring to think that people who Know What They’re Doing™ are still looking after it just in case, so let’s review the dates at which various organizations plan to stop support for Python 2.

The Python Software Foundation has announced end of support on 1st January 2020. But the Debian GNU/Linux distribution (which has a good security team) have already decided to ship Python 2 with Debian 10, which is currently aiming for a mid-2019 release, meaning the Debian security team will most likely support it until 2022 and the Debian long-term support team (which is not the security team but does include people who know about security) until 2024. The more-commercial Ubuntu distribution (which is based on Debian) has included Python 2 in their 18.04 ‘long-term support’ release, which, they announced in November 2018, will be supported for 10 years (double the usual 5 years of previous long-term support releases), and have therefore committed to support Python 2 until 2028. Also Red Hat Enterprise Linux 7 includes Python 2 and has committed to support until 2024. (Both companies have decided to drop Python 2 in their following long-term versions: Ubuntu 20.04 and RHEL 8.) Therefore the timetable is currently looking like this:

• 2020: upstream support ends on January 1
• 2022: likely end of support from Debian’s main security team
• 2024: end of support from Red Hat + likely end of Debian’s long-term support
• 2028: end of support from Ubuntu

But if you want to run Python 2 through to 2028, you had better have control over which Linux distribution is on your servers. Just because Ubuntu 18.04 has support planned until 2028, won’t necessarily stop your local sysadmin from updating to Ubuntu 20.04 in mid-2020 and saying ‘sorry that means our Python 2 interpreter has gone’ and you’ll have to persuade them to install a package which Canonical’s update tool labels as ‘unsupported’ even though it is probably the exact same package that is still supported by 18.04 (plus is likely to have support from Debian till 2024: Canonical seems to refer to Debian support as ‘community support’ and implies it’s somehow less reliable than Canonical’s commercial support, although this is not necessarily the case as Debian has very high standards). On the plus side, Ubuntu’s do-release-upgrade script currently defaults to keeping these ‘no longer supported’ packages, so if the local sysadmin doesn’t do something different then you might still get Python 2.

It’s probably a good idea to call ‘python2’ explicitly rather than rely on the distribution mapping the ‘python’ command to ‘python2’, as some distributions are already discussing making the ‘python’ command mean Python 3, and/or removing it altogether so scripts must specify a version.

Compiling Python 2 in your home directory is doable: it’s

  ./configure --prefix=/path/goes/here && make &&  make install

and it takes over 120 megabytes by default (although 95M of this is libraries you might be able to thin down if you don’t use all of them). Or you could use a home server (the Raspberry Pi’s ‘Raspbian’ distribution is based on Debian and should hopefully continue to contain Python 2 as long as Debian does, plus if you do need to start installing things in your home directory then you are likely to have far more space to do so on a home server) but bandwidth might be an issue for some applications.

The most compatible alternative implementation of Python 2 appears to be PyPy, and it seems likely that PyPy’s support for Python 2 syntax will continue beyond 2020 although I have not found any clear statement about this. But C-based extension library modules like ‘pycurl’ tend not to work on PyPy (at least not without extensive changes) although ‘ctypes’ is supported. So whether PyPy is a feasible way forward depends on your project. There is also Google’s apparently short-lived effort to write a transpiler from Python 2 to Go (the most active fork appears to be at https://github.com/grumpyhome) but it’s anyone’s guess whether this will be production-ready by 2020, and it is unlikely to support C extension modules at all (even ctypes).

Then there is Cython (you could try ‘cython -2’) but its support for Python 2 syntax is not complete, for example you can’t currently unpack tuples in function parameter lists and unichr is missing. If you do get it to work, you will end up with an automatically-generated C program that calls into Python’s mechanism for C extension modules: you’ll need a correctly set-up installation of Python’s developer packages to compile this, but it can be from Python 3 even if your original source file was Python 2. However, once again this is a method that will not work with all projects. Continuing to run the stock implementation of Python 2 is the only method that’s ‘sure’ to work.

And then there is the option of trying to port your code to Python 3. Python’s ‘2to3’ tool is supposed to help with this, but it doesn’t do everything: urllib-related libraries, for example, have changed in Python 3 in more ways than the 2to3 tool’s simple renaming will handle, so you can’t just run 2to3 and expect your code to work: you need to have full test coverage and/or inspect it all very carefully! This is the reason why many codebases have been slow to migrate off Python 2 in the first place. I suspect that developers coerced into going through an entire codebase with a fine-toothed comb to get it out of Python 2 might decide to use that effort in ‘escaping’ from the Python ecosystem altogether and port it to a more stable programming language of their choice.

Meanwhile it is possible to continue using Python 2.7 (in your home directory if necessary) and be reasonably confident of third-party security support until mid-2028, after which you’ll be relying on 18 years of peer review to have done their job, and/or look out for vulnerability announcements yourself and take whatever action needed to make them irrelevant to your use-case. That might be hard to explain to corporate management though.

Silas S. Brown Silas is a partially-sighted Computer Science post-doc in Cambridge who currently works in part-time assistant tuition and part-time for Oracle. He has been an ACCU member since 1994.

Notes: 

More fields may be available via dynamicdata ..