End of Life for Python 2 — Now What?
End of Life for Python 2 — Now What?
Now that Python 2 has reached its End of Life, what should you do?
Join the DZone community and get the full member experience.Join For Free
If you’re like most Python developers, you’ve been working with Python 2 for years. Now, with the Python Software Foundation announcing the End of Life (EOL) for Python 2, the core development team will no longer support, update, or provide new versions of Python 2 as of January 1, 2020.
As a developer, you’d probably prefer to adopt Python 3, but for various reasons (corporate policy, lack of resources, legal restrictions, contractual obligations, etc.), your organization may be stuck maintaining existing applications on Python 2 (or even continuing to develop with Python 2) for the foreseeable future. So what can you do?
Impact of Python 2 EOL
As you probably noticed, your Python 2 applications are still running past Jan 1, 2020. They didn't self destruct, but they will become less reliable and more vulnerable over time as bugs, security issues, and CVEs crop up. Some things to think about:
- There will be no official support forthcoming for the Python 2 interpreter or the Python 2 standard libraries from the Python 2 core team. Additionally, there are no guarantees that the Python Packaging Authority (PyPA) or the Python Package Index (PyPI) will continue to support Python 2 for any length of time past the EOL date.
- Community developers working on Python 2 and Python 3 versions of their packages will de-prioritize working on their Python 2 code. In fact, many authors have indicated that all work on their popular Python 2 packages will be dropped in 2020 in favor of Python 3 development only.
- Vendors that offer Python 2 distributions today (such as Linux vendors, Docker, cloud providers, etc) will likely phase out their support for Python 2 over time. While Python 2 offerings are unlikely to disappear from their catalog on January 1, 2020, the scope of their support may become limited over time.
For example, AWS’s Lambda support page states that deprecated runtimes can’t be used to create new functions, but can still be used to process invocation events.
You might also like: Tips and Tricks for Upgrading From Python 2 to Python 3
Python 2 EOL Support Options
If you’re unwilling or unable to migrate your Python 2 applications to Python 3, the future is not as precarious as you might think. The IT landscape is littered with deployments of operating systems (Windows XP anyone?), applications (such as Internet Explorer 6, which stubbornly refused to die) and older versions of various tech stacks (COBOL, Java, etc.) that are officially sunset but continue to be in use.
In each of these cases, organizations typically adopt one of two commonly used tactics:
- Support It Yourself — If you’ve been working with Python 2 for years, you’re familiar with supporting your own Python 2 code. But that self-serve support typically extended to only investigating emerging bugs/vulnerabilities and applying official updates or upgrades as necessary. Things are different when you’re on the hook for patching/upgrading a package you did not create yourself, testing with its dependencies, and even updating those dependencies, if required.
- Find a Commercial Vendor — In some cases, you can purchase extended support from a third-party commercial support vendor.
Self-Support vs Commercial Support for Python 2
If you make the decision to support Python 2 yourself, there are a number of options you should consider, including:
- Internal Python 2 Experts — Becoming the dedicated go-to person for Python 2 expertise in your organization can be a valuable (if limited) career move. Alternatively, you could always suggest hiring a Python 2 expert from the community. Unfortunately, there’s no guarantee these experts won’t leave the organization, and as Python 2 ages, it will be harder and harder to hire a replacement.
- Outsourcing — Traditional consulting companies are always willing to take on your Python 2 support and maintenance work, allowing you to move on to newer technology stacks where you can add more value to the organization. Of course, as Python 2 expertise dries up over time, outsourcing fees may become prohibitively expensive.
- Sponsorship — In the same way that organizations can sponsor open source authors to work on current technologies via services like OpenCollective, it may be possible to sponsor Python 2 authors to continue to maintain the one or two key packages you require. Unfortunately, if your application has dozens of key packages, such a solution simply won’t scale.
No matter which support option you choose, here are some key criteria you'll want to sure to cover:
- Support for both the Python 2 core language and standard libraries, as well as the third-party, open source packages, libraries, and modules listed in the Python Package Index (PyPI).
- Back-ported security fixes implemented in Python 3 core language code and third-party packages.
- Resolution of Python 2 specific issues, which will typically need to be done in conjunction with the Python community.
Opinions expressed by DZone contributors are their own.