Python 2 has been prematurely declared dead numerous times now, including:

  • Way back in 2008, when the volunteers who make and take care of the Python programming language first announced that Python 2 would be sunset in 2015.
  • In 2014, it was determined that too few users had migrated to Python 3, so the EOL date was reset to 2020.
  • January 1, 2020, when Python 2 was officially declared EOL, although there was one more Python core release still planned, and many third-party maintainers continued to release new versions of their Python 2 packages. 
  • On April 20, 2020, the final version of 2.7.18 was released to address a number of critical bugs.

While the volunteer Python team and most third-party package developers have moved on and no longer provide fixes, patches or new releases for Python 2, operating system providers like Red Hat, Ubuntu and others continue to provide support and security fixes for the core language. And ActiveState continues to provide fixes for selective third party packages, as well. 

Why? Because like most popular programming languages, Python 2 is hard to kill off. As I explained in a recent blog post, The Python 2 Threat In Your Supply Chain Is Real, we may have killed Python 2 in prod, but the evidence points to the fact that we’ve buried it in non-prod:

Python 2 Ghost

The Problems with Migrating from Python 2 To Python 3

We know from our Python 2 End Of Life Survey that at least two-thirds of organizations have already migrated their Python 2 applications. In our discussions with many of the remaining one-third of companies over the past two years, we know that: 

  • Some are still in the process of migrating (yes, even two years later).
  • Some are currently blocked from migrating, waiting on a Python 3 version of one of more key packages. 
  • And others continue to evaluate their application risk as their existing Python 2 applications have become less reliable and more vulnerable over time due to bugs, security issues and CVEs.

When it comes to migration, back in January 2020, the migration package “six” (which enables Python 2 code to work on both Python 2 and Python 3), was the second most downloaded package according to pypistats.org:

Six Downloads 2020

Two years later In January 2022, it would seem that more Pythonistas are focused on AWS rather than migration given six’s present position on the list:

Six Downloads 2022

Migration work may have slowed, but the move to Python 3 is not quite over with and done just yet. 

Python 2 Migration Laggards

The Python Wheels site maintains a list of the top 360 third party packages by downloads on pypistats.org. It indicates that only 18 of the most popular packages have yet to support Python 3’s new packaging standard, but in fact only a handful have yet to add Python 3 support. Of course, that’s no comfort if you’re still dependent on one of the laggards, which include such notables as:

  • Docopt – used to create command line interfaces.
  • pySFTP – a simple interface for your secure FTP needs. 
  • Retrying – provides a simple way to retry a function when an exception occurs.

There also seem to be a number of industries that are lagging when it comes to Python 3 adoption, notably:

  • CAD – Closely scanning the internet for Python 2 use cases will show you that not only CAD, but various other animation and VFX tools still have some Python 2 based functionalities.
  • Bioinformatics – Python 2.7 continues to be used as the preferred version by many medical researchers even in 2022
  • GIS – Popular names in the GIS space have applications that rely on Python 2 and need to be carefully supported and/or migrated.

Conclusions

Python 3 has been embraced by the Python community, but Python 2 is far from dead. While Python 2 is no longer the way that developers learn Python, older Pythonistas still continue to maintain repositories of Python 2 code simply because the effort to migrate or rewrite it isn’t worth the time and resources involved. 

However, supporting an aging code base – especially one that contains third-party packages you didn’t create – only gets more difficult over time as bugs and security vulnerabilities inevitably crop up. Additionally, as open source supply chain attacks increase, the risk of running Python 2 code is quickly becoming unmanageable.

Contact us for a free risk assessment of your Python 2 codebase.

As an alternative, ActiveState has been providing Python 2 support since EOL on January 1 2020. Our customers receive timely updates to security issues so they can continue to safely run their Python 2 applications, services and systems.

Interested? Contact us for a free risk assessment of your Python 2 codebase. Provide us with a file to scan and we will email you a personalized Python 2 security report shortly.

Need More Information?

Recommended Reads

The Python 2 Threat in Your Supply Chain Is Real

Python 2 to 3 Migration: A Developer’s Experience