Programming languages evolve over time. It will likely not cause headlines when Java 8 goes end of life in December 2020. Most “Java 8” programs will, after all, “just run” on new versions of Java, as the language tends to be backwards compatible.
That isn’t quite the case with Python 3.
The most well-known difference with Python 3 is the humble print command. In Python 2, it’s a statement (no parenthesis) and in Python 3 it is a function. That means old code won’t run. The most important difference may be integer division, which now returns a float by default. That is worse. It means the code will compile—and behave differently in subtle ways. Upgrading without thinking isn’t just “out,” it is beyond comprehension.
How we got here
This change isn’t a surprise. The Python 2 codebase is 20 years old, with an initial release dating to 2000. When Python 3 was released in 2008, Python 2 had a strong install base and a group of programmers too busy inventing Web 2.0 to spend time running-in-place and converting. As a result, the Python Software Foundation extended end-of-life for Python 2 out from a planned 2015 date to 2020.
When creator Guido Van Rossum made the announcement at pyCon 14, Python was at version 2.7. His initial slide was a “2.8,” surrounded by a red circle with a slash through it. In other words, the only improvements in Python 2 over the next five years would be fixes, security patches, and so on. As a result, the open source community that maintains Python needed to maintain two code branches.
The Python Software foundation set Jan. 1, 2020 as the expiration date for that second code branch. It announced a final push for this month April 2020, when all active development will cease. The Python 2 clock has expired. The time to upgrade or punt is now.
What does unsupported mean?
You could, of course, simply not upgrade. Because Python is free and open software, “going unsupported” just means no more patches. The compiler will still run programs written for Python 2. There will be no pop-ups forcing you to the next version. The vast majority of Python users had no commercial support in the first place. Visual Basic 6, for example, went off extended support in 2008.
Yet one of my customers still has a series of Visual Basic 6 programs in their data center, processing transactions every day. The systems that need maintenance they convert to .NET (sometimes) if the change is large enough. I asked Cameron Laird, a vice president at PhaseIT and an invited member of the Python Software Foundation, what the big deal was.
Cameron explained two major issues. First, for ongoing development, new modules will increasingly use Python 3. That means support for new tools, drivers, databases, things that simply have not been invented yet. Continuing to use Python 2 means walling yourself off from the subroutines other people are creating to solve common problems.
The more serious problem Cameron pointed out is security. He puts it this way: “Python 2 doesn’t have the thriving community of developers supporting it to patch security holes that Python 3 does.” By the end of the year, it won’t have a community at all.
Wait a minute. Does software rust? If Python 2 is 20 years old, and has essentially only been on patched maintenance for the past five or six, shouldn’t it just keep right on ticking?
New uses, new abuses
Laird points out the use cases for Python change as the environment shifts around it. New DNS versions, new databases, web servers, microservices can all have new versions, with new vulnerabilities. Python sits in between these systems, and has integration points using modules which might not be patched anymore. Of time, the very nature of what Python is doing, and what it is working with can change, creating “abuse cases” that did not exist in the past.
While Python does not rust, Cameron does point to serious security issues in Python 2 discovered less than a year ago and patched today. Those patches stop rolling this month.
SEE: Python programming language: A cheat sheet (free PDF) (TechRepublic)
Running your upgrade
Upgrading code from Python 2 to Python 3 doesn’t have to be that hard. A computer program can look for print “hello world” and convert it to print (“hello world”). Likewise Python 3 has a new operator, the double-slash, or “//”, which does old-style Python division. There are plenty of guides to coding changes and even a fully supported, free conversion program called “2to3.” Besides picking up some new habits, the conversion looks, well, easy.
Laird agrees. “Part of my business is helping organizations migrate from 2 to 3. I go in with the assumption that we can migrate from 2 to 3 and we can do it without trauma, without blowing budgets or schedules. With very few exceptions I find we can do it without specific expertise or training. Many individuals believe the conversion will mean rewriting their world—there is a lot of uncertainty and fair. There doesn’t need to be. It’s feasible.”
He also has customers like my Visual Basic 6 shop, that have systems deep inside the data center, not exposed to the internet, running code that has not changed for months or years that does one thing and does it well. There have been a few cases where Laird did not recommend an upgrade, or, at least, did not disagree strongly when management decided to leave the systems running. Activestate, long known for making Windows distributions of Perl and Python, also has an extended commercial support offering for Python 2 after the December cutoff date.
Since Python 3 was released 12 years ago, many programmers today think of this as a nonissue; they started with Python 3 and never looked back. One of Python’s great strengths, however, is its versatility. Many systems administrators were running hand-rolled Python scripts before “DevOps” was a term, storing the code in backups, not version control. It’s very possible your organization is running little bits of Python in places undocumented or even unknown.
It might be time to check.