Sorting out the dates of Python 2's 'end of life'

January 12, 2020

Probably like many people, I've been hearing for years now that January of 2020 was the end of life for Python 2, specifically January 1st. As a result, I was rather surprised to hear that there will be another release of Python 2 in April, although I could have read the actual details in PEP 373 and avoided this.

The official dates, from PEP 373, are:

Planned future release dates:

  • 2.7.18 code freeze January, 2020
  • 2.7.18 release candidate early April, 2020
  • 2.7.18 mid-April, 2020

What this actually means is not clear to me, given the four month delay between the code freeze (now) and the planned release of even a 2.7.18 release candidate (April). At a minimum, I assume that the code freeze blocks new features, should anyone want to submit any. I suspect that the Python people would not accept fixes for new bugs or for existing bugs that did not have some version of a fix accepted before the code freeze. I assume that Python developers will still accept fixes for accepted bugfixes, if testing shows that any have problems.

(If Python isn't going to accept changes into what will be released as 2.7.18 for any reason at all, they might as well release tomorrow instead of in four months.)

Although the details are set out in PEP 373, this way of describing Python 2's end of life is a little bit unusual and different from what I (and likely other people) expected from an 'End of Life' date. The usual practice with EOL dates is that absolutely nothing will be released beyond that point, not that main development stops and then a final release will be made some time later.

(This is what Linux distributions do, for example; the EOL date for a distribution release is when the last package updates will come out. I believe it's similar for the BSD Unixes.)

It's very unclear to me how Linux distributions (and the BSDs) are likely to handle Python 2 versions in light of this. At least some of them will still be packaging Python 2 in versions released beyond April of 2020. They might freeze their Python 2 version on the current 2.7.17 (or whatever they already have), or upgrade to 2.7.18 as one last Python 2 (re-)packaging.

Comments on this page:

Suspiciously close to the Ubuntu 20.04 LTS release... I wonder if there’s some coordination.

By Anonymous Coward at 2020-01-13 02:28:01:

"Mid-April, 2020" -- PyCon US this year takes place April 15-23.

So the most likely explanation is they want to do something festive at PyCon for the final packaged release, but don't want to incur additional support burden for accepting/fixing bugs in Python 2 past the long-announced EOL date of 2020-01-01.

RHEL 8 will support Python 2 through June 2024. Fedora has already switched to Python 3 as the default Python, but we continue to ship 2.7. I suspect that we'll continue to do that for at least a few more releases. Perhaps until RHEL 8 drops support, but I wouldn't bet on that.

By cks at 2020-01-13 13:56:55:

Python's timing is actually very bad for Ubuntu 20.04, because Ubuntu generally freezes package versions at least a couple of months before a new release. If Python 2.7.18 was released now, it would likely make 20.04, but with an April release it will have to be a post-release update (if at all, although Ubuntu 18.04 did update to 2.7.17).

Written on 12 January 2020.
« How I now think you want to configure Apache for OCSP stapling
Link: Mercurial's Journey to and Reflections on Python 3 »

Page tools: View Source, View Normal, Add Comment.
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Sun Jan 12 22:18:50 2020
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.