Python 2 EOL – Now What?

Python 2 EOL is here
Python 2 Support Update 2022: Even if you’re only running Python 2 in non-production environments, it is still vulnerable. The increasing threat of supply chain attacks makes it more important than ever to secure your Python 2 code.

ActiveState continues to provide Python 2 support to help organizations safely run their Python 2 applications, services, and systems, at a fraction of the cost they spend in developer hours maintaining them.

Read more about ActiveState’s Python 2 support >

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

Your Python 2 applications will keep running past Jan 1, 2020 – they won’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 deprioritize 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.

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. ActiveState is a good example.

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.

Alternatively, ActiveState offers commercial support for Python 2 beyond the EOL date, providing security fixes for your Python 2 applications after community support expires. The offering includes:

  • 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).
  • Backported security fixes implemented in Python 3 core language code and third-party packages.
  • Resolution of Python 2 specific issues by ActiveState’s Python experts in conjunction with the Python community.

With more than 20 years of experience supporting Python for enterprises, ActiveState can help you maintain your Python 2 code going forward in much the same way you maintain it today.

Commercial Python support is available today for both Python 2 and Python 3. Extended support for Python 2 begins on Jan. 1, 2020. To learn more, you can:

Recent Posts

Tech Debt Best Practices: Minimizing Opportunity Cost & Security Risk

Tech debt is an unavoidable consequence of modern application development, leading to security and performance concerns as older open-source codebases become more vulnerable and outdated. Unfortunately, the opportunity cost of an upgrade often means organizations are left to manage growing risk the best they can. But it doesn’t have to be this way.

Read More
Scroll to Top