Python 2 EOL: How to survive the end of Python 2

As of January 1, 2020, the 2.x branch of the Python programming language is no longer supported by its creators, the Python Software Foundation. This date marks the culmination of a drama that has stretched on for years—the transition from an older, less capable, widely used version of Python to a newer, more powerful version that still trails its predecessor in adoption.

It’s high time. Python 3, with countless technical and end-user enhancements over Python 2, has never been in a better position to permanently displace Python 2. The vast majority of popular packages hosted in the PyPI repository, the first-stop shop for reusable Python code, support Python 3. Python 3 has become the default Python interpreter for many Linux distributions. And most every recent book, coding academy, and online tutorial recommends Python 3 for beginners.

Now the bad news. Python 2, like Windows 7 (or Windows XP!), will be with us for years to come. Many of us will continue to rely on apps written in Python 2. Some of us will even continue to use Python 2 for new apps, due to internal restrictions. What should you do if you’re stuck with Python 2 in what is fast becoming a Python 3 world? Let’s look at the options. 

Python 2 end of life: What it means

The first and most important thing to understand about Python 2 going EOL (end of life): Python 2 applications will still run. Don’t think of this as a Millennium Bug issue, where Python 2 applications all magically grind to a halt on January 1, 2020. There just won’t be any more official support for Python 2 from the core Python development team.

Here is what the Python 2 EOL means in practical terms:

• Official bug fixes and security patches for Python 2 will cease. No newly discovered problems in the Python 2 interpreter or the Python 2 standard library will be fixed by the core development team. However, commercial vendors could maintain Python 2 on their own, and other third parties could fork the Python 2 codebase and continue where the core team left off. (More on this later.)
• Third-party Python projects will abandon Python 2. Libraries that have supported both Python 2 and Python 3 will begin to devote their resources to Python 3 exclusively. Many of these projects are volunteer-run, and it’s far less work to support just one version of the language. Each project will decide on Python 2 support for itself, but many major Python projects are pledging to drop Python 2 support entirely by 2020.
• Platform support for Python 2 will wane. Linux distributions and cloud service providers may continue to include the Python 2 runtime. But expect support for Python 2 to become less robust over time. It will almost certainly still be possible to run a containerized version of Python 2 on a cloud platform, but there’s no guarantee that cloud service providers will continue to maintain their own Python 2 containers.

If you are stuck with Python 2 applications, how should you deal with the absence of Python 2 support? The best thing to do in the long term is find a strategy to remove all of your dependencies on Python 2. But that is just the first of many options. 

Transition away from Python 2

Leaving behind Python 2 for Python 3 may be easier than you expect, depending on the size of the code base and the external dependencies. Python’s official documentation has some straightforward steps you can take to determine if your project is “future-proof”—i.e., can be used in Python 3 with little or no adjustment. One of the best first steps you can take is to use the caniusepython3 package to figure out which, if any, components or dependencies would block a migration.

If you’re stuck with Python 2 because a particular component of an application works only on Python 2, start by transitioning away from that component. See if an alternative exists that is Python 3 compatible, and then rebuild the application from that point outwards. The idea is to look for the smallest places where one’s dependencies on Python 2 lie, and address them.

The very least you can do, if you must remain on Python 2 in some form, is start by migrating to the latest version of Python 2—Python 2.7.16 as of this writing—and use that as the point of departure for Python 3. That way you’ll benefit from the bug fixes that will be available for Python 2.7 before its official end of life.

Use an alternative Python 2 runtime

If altering the Python 2 code base isn’t a workable proposition, another alternative is to use a different Python 2 runtime, developed by a third party. Alternative Python 2 runtimes may have a longer support window than Python 2 itself.

Tauthon

Tauthon is a fork of Python 2.7.18 “with new syntax, built-ins, and libraries backported from Python 3.x,” according to the project’s README. Tauthon also includes, whenever the maintainers can provide them, fixes and patches for the language. In theory Tauthon should work as a drop-in replacement for Python 2.7. The most recent release as of this writing, Tauthon 2.8.2, includes function annotations, keyword-only arguments, async/await syntax, and other features formerly available only in Python 3.

PyPy

PyPy, the just-in-time accelerated runtime for Python, uses Python 2 as a key part of its own internal infrastructure, and has long supported Python 2 as its main version. The documentation for the project claims “since RPython [the foundation of PyPy] is built on top of Python 2 and that is extremely unlikely to change, the Python 2 version of PyPy will be around ‘forever,’ i.e. as long as PyPy itself is around.” PyPy might pose compatibility or performance problems with some Python packages that rely on C extensions, although PyPy’s development team works constantly to iron out those issues.

IronPython

IronPython, a Python implementation for the .Net runtime, has a Python 2 version still receiving active support. Its current roster of developers have declared they are not likely to support Python 2 past 2020, the better to concentrate on IronPython3. However, that doesn’t mean someone else couldn’t continue such support on their own.

Cython

Another possibility, although with a limited window of support as well, is Cython. Cython compiles Python to C with optional typing for performance enhancements and has supported Python 2 since its inception. It’s possible to use Cython to convert Python 2 code into C for continued use as a “frozen” binary. You might even gain a performance boost by doing so, depending on the nature of the application. (Programs that are mainly I/O bound won’t see much improvement.)

However, Cython plans to drop Python 2 support by the end of the year. This doesn’t mean that Python 2 programs won’t compile to Cython anymore, only that Cython code using Python 2 syntax would need to be compiled using Python 3. 

Buy extended Python 2 support from a vendor

One long-term solution is to obtain support from a vendor of Python solutions. ActiveState, creator of the ActivePython distribution and the Komodo IDE, offers commercial support for customers who want to stay with Python 2, or who want to migrate to Python 3 by identifying the parts of their Python stack that must be rewritten in Python 3.

Some vendors provide support for Python 2 as part of its presence in another supported product. Red Hat Enterprise Linux versions 6 and 7 include Python 2, so any support contracts purchased from Red Hat for those versions of the OS will include continuing support for Python 2 through the support lifetime of the product.

If you’re using Python 2 by way of a cloud service, there’s a chance the service will continue to support Python 2 in its own way. AWS, for instance, has stated it will provide security patches for its Python 2.7 runtime until December 31, 2020, although this does not apply to any third-party Python 2.7 packages.

A third option is to purchase support from a consulting firm or contractor. The level of support they give you would vary depending on your needs and ambitions. It could consist of coming up with a transition plan to move away from Python 2 and having any dependent software rewritten (probably the best long-term strategy), or manually merging patches for Python 2 into a custom build of the runtime (ambitious and complex).

Maintain Python 2 yourself

Python is an open source project. There’s nothing to stop you from implementing any needed fixes yourself. If the fix is a change to Python’s standard library, that typically isn’t too hard, as most of the Python standard library is itself written in Python. But if you need to make changes to a C module used by Python in the standard library, or the CPython interpreter, that would be more challenging. You’ll need to know C and be familiar with CPython’s internals to accomplish this.

Do nothing

If it ain’t broke, don’t fix it. That’s the strategy many businesses used with Windows NT and Windows 2000 when those operating systems went end-of-life. Python applications that are for internal use only and that aren’t exposed to the public Internet could in theory be run indefinitely.

Virtual machines and containerization provide ways to keep these kinds of applications alive and well in a controlled environment. You can “freeze” a given edition of the Python 2 runtime into a container image or VM, along with its standard library, the modules needed for your app, and the application itself.

That said, any legacy app, even one that has no external exposure, should be reassessed regularly. In every case, the best long-term strategy for Python 2 users is to migrate to Python 3. Python 2, as great as it has been, is something to move past.

Read more about Python

• What is Python? Powerful, intuitive programming
• What is PyPy? Faster Python without pain
• What is Cython? Python at the speed of C
• Cython tutorial: How to speed up Python
• How to install Python the smart way