The Python 2.6 Tipping Point Has Arrived

It’s been exactly three years since the last release of python 2.6, and yet it’s still hanging around like some kind of living-dead zombie. What should we do about it?

A few months ago I was working on a new pytest plugin , and I noticed that my continuous integration tests against Python 2.6 were failing because the flake8-import-order module, which I was using for linting, was not compatible with Python 2.6.

I knew that Python 2.5 is sufficiently old and crufty and shouldn’t be supported, but it’s so simple to support 2.6, right? You just have to change set comprehensions like {a, b} to use the set built-in instead, like set((a, b)) , and maybe some other stuff, but that seems a small price to pay in exchange for Supporting More Users.

Plus, I figured, “If I can make this module compatible with Python 2.6, it can’t hurt, right? At the very least, it might help some folks.”

So I made this PR:

And it was quickly made clear to me that this was not, at all, a good idea.

Bringing back the dead

What I didn’t realize is that Python 2.6 is much more dead than I had thought. In fact, End-of-Life for 2.6 was announced in late 2013, and the last release (and thus, the end of support for it) took place on October 29th, 2013 :

With the 2.6.9 release, and five years after its first release, the Python 2.6 series is now officially retired. All official maintenance for Python 2.6, including security patches, has ended. For ongoing maintenance releases, please see the Python 2.7 series.

So essentially, by creating my seemingly harmless PR, I was saying: “Hey, let’s keep supporting some really old, potentially insecure software, shall we?”

You already told me not to

Although I had somehow missed the release notes, the fact that 2.6 shouldn’t be supported really shouldn’t have come as much of a surprise, because we’ve all been told before.

In April of 2015, Daniel Holth, a CPython core developer, told us how we could all stop supporting Python 2.6 (for free) :

The affected users have more options than they may realise, and upstream open source developers shouldn’t feel obliged to donate their own time to help end users cope with organisations that aren’t yet able to upgrade their internal infrastructure in a more timely fashion.

A few months later, Brett Cannon, everyone’s favorite snarky Canadian, asked us all nicely to stop using Python 2.6, please :

If you’re using Python 2.6 and you’re not paying someone to support it for you, please upgrade to Python 2.7. You’re running software that is not being maintained for security or bugfixes and so you should consider upgrading for those reasons alone.

And much more recently, Donald Stufft, one of the authors of pip , asked on the “Distribution Utilities Special Interest Group” mailing list “When can we kill Python 2.6 support?” :

I would like to take a look at Python 2.6 and try and figure out if we’re at a point that we can deprecate and drop it, and if not what is such a point.

And the general consensus was more or less: “How about… now?”

So let’s bury Python 2.6 already

The reason I’m calling this a tipping point is because in the last few months, I’ve noticed more and more prominent Python projects either proposing to drop support for 2.6 soon, or just outright dropping it. Here’s just a sampling of recent issues and PRs:

celery/kombu clarkduvall/serpy FactoryBoy/factory_boy fedora-infra/fedmsg google/oauth2client hynek/structlog idan/oauthlib kennethreitz/dj-database-url ktbyers/netmiko mkdocs/mkdocs mozilla/bleach msgpack/msgpack-python nicolargo/glances pallets/flask-ext-migrate PyCQA/flake8 PyCQA/pydocstyle pyinvoke/invoke Pylons/pyramid Pylons/webob pypa/pip pypa/readme_renderer rg3/youtube-dl robotframework/Selenium2Library scrapy/scrapely scrapy/scrapyd sloria/TextBlob twisted/twisted