Python 2.7.18, the end of an era
([Development] Apr 20, 2020 16:12 UTC (Mon) (ris))
- Reference: 0000818000
- News link: https://lwn.net/Articles/818000
- Source link:
Python 2.7.18 is out. This is the last release and end of support for Python 2. " Python 2.7 has been under active development since the release of Python 2.6, more than 11 years ago. Over all those years, CPython's core developers and contributors sedulously applied bug fixes to the 2.7 branch, no small task as the Python 2 and 3 branches diverged. There were large changes midway through Python 2.7's life such as PEP 466's feature backports to the ssl module and hash randomization. Traditionally, these features would never have been added to a branch in maintenance mode, but exceptions were made to keep Python 2 users secure. Thank you to CPython's community for such dedication. "
From :
"Benjamin Peterson" <benjamin-AT-python.org>
To :
python-dev-AT-python.org
Subject :
[RELEASE] Python 2.7.18, the end of an era
Date :
Mon, 20 Apr 2020 10:06:06 -0500
Message-ID :
<491cf94d-7887-407e-926f-c92081717dd5@www.fastmail.com>
Archive-link :
[1]Article
I'm eudaemonic to announce the immediate availability of Python 2.7.18.
Python 2.7.18 is a special release. I refer, of course, to the fact that "2.7.18" is the closest
any Python version number will ever approximate e, Euler's number. Simply exquisite!
A less transcendent property of Python 2.7.18 is that it is the last Python 2.7 release and
therefore the last Python 2 release. It's time for the CPython community to say a fond but firm
farewell to Python 2. Users still on Python 2 can use e to compute the instantaneously compounding
interest on their technical debt.
Download this unique, commemorative Python release on python.org:
https://www.python.org/downloads/release/python-2718/
Python 2.7 has been under active development since the release of Python 2.6, more than 11 years
ago. Over all those years, CPython's core developers and contributors sedulously applied bug fixes
to the 2.7 branch, no small task as the Python 2 and 3 branches diverged. There were large changes
midway through Python 2.7's life such as PEP 466's feature backports to the ssl module and hash
randomization. Traditionally, these features would never have been added to a branch in maintenance
mode, but exceptions were made to keep Python 2 users secure. Thank you to CPython's community for
such dedication.
Python 2.7 was lucky to have the services of two generations of binary builders and operating
system experts, Martin von Löwis and Steve Dower for Windows, and Ronald Oussoren and Ned Deily for
macOS. The reason we provided binary Python 2.7 releases for macOS 10.9, an operating system
obsoleted by Apple 4 years ago, or why the "Microsoft Visual C++ Compiler for Python 2.7" exists is
the dedication of these individuals.
I thank the past and present Python release managers, Barry Warsaw, Ned Deily, Georg Brandl, Larry
Hastings, and Łukasz Langa for their advice and support over the years. I've learned a lot from
them—like don't be the sucker who volunteers to manage the release right before a big compatibility
break!
Python 3 would be nowhere without the critical work of the wider community. Library maintainers
followed CPython by maintaining Python 2 support for many years but also threw their weight behind
the Python 3 statement (https://python3statement.org). Linux distributors chased Python 2 out of
their archives. Users migrated hundreds of millions of lines of code, developed porting guides, and
kept Python 2 in their brain while Python 3 gained 10 years of improvements.
Finally, thank you to GvR for creating Python 0.9, 1, 2, and 3.
Long live Python 3+!
Signing off,
Benjamin
2.7 release manager
--
Python-announce-list mailing list -- python-announce-list@python.org
To unsubscribe send an email to python-announce-list-leave@python.org
https://mail.python.org/mailman3/lists/python-announce-li...
Support the Python Software Foundation:
http://www.python.org/psf/donations/
[1] https://lwn.net/ml/python-dev/491cf94d-7887-407e-926f-c92081717dd5@www.fastmail.com
From :
"Benjamin Peterson" <benjamin-AT-python.org>
To :
python-dev-AT-python.org
Subject :
[RELEASE] Python 2.7.18, the end of an era
Date :
Mon, 20 Apr 2020 10:06:06 -0500
Message-ID :
<491cf94d-7887-407e-926f-c92081717dd5@www.fastmail.com>
Archive-link :
[1]Article
I'm eudaemonic to announce the immediate availability of Python 2.7.18.
Python 2.7.18 is a special release. I refer, of course, to the fact that "2.7.18" is the closest
any Python version number will ever approximate e, Euler's number. Simply exquisite!
A less transcendent property of Python 2.7.18 is that it is the last Python 2.7 release and
therefore the last Python 2 release. It's time for the CPython community to say a fond but firm
farewell to Python 2. Users still on Python 2 can use e to compute the instantaneously compounding
interest on their technical debt.
Download this unique, commemorative Python release on python.org:
https://www.python.org/downloads/release/python-2718/
Python 2.7 has been under active development since the release of Python 2.6, more than 11 years
ago. Over all those years, CPython's core developers and contributors sedulously applied bug fixes
to the 2.7 branch, no small task as the Python 2 and 3 branches diverged. There were large changes
midway through Python 2.7's life such as PEP 466's feature backports to the ssl module and hash
randomization. Traditionally, these features would never have been added to a branch in maintenance
mode, but exceptions were made to keep Python 2 users secure. Thank you to CPython's community for
such dedication.
Python 2.7 was lucky to have the services of two generations of binary builders and operating
system experts, Martin von Löwis and Steve Dower for Windows, and Ronald Oussoren and Ned Deily for
macOS. The reason we provided binary Python 2.7 releases for macOS 10.9, an operating system
obsoleted by Apple 4 years ago, or why the "Microsoft Visual C++ Compiler for Python 2.7" exists is
the dedication of these individuals.
I thank the past and present Python release managers, Barry Warsaw, Ned Deily, Georg Brandl, Larry
Hastings, and Łukasz Langa for their advice and support over the years. I've learned a lot from
them—like don't be the sucker who volunteers to manage the release right before a big compatibility
break!
Python 3 would be nowhere without the critical work of the wider community. Library maintainers
followed CPython by maintaining Python 2 support for many years but also threw their weight behind
the Python 3 statement (https://python3statement.org). Linux distributors chased Python 2 out of
their archives. Users migrated hundreds of millions of lines of code, developed porting guides, and
kept Python 2 in their brain while Python 3 gained 10 years of improvements.
Finally, thank you to GvR for creating Python 0.9, 1, 2, and 3.
Long live Python 3+!
Signing off,
Benjamin
2.7 release manager
--
Python-announce-list mailing list -- python-announce-list@python.org
To unsubscribe send an email to python-announce-list-leave@python.org
https://mail.python.org/mailman3/lists/python-announce-li...
Support the Python Software Foundation:
http://www.python.org/psf/donations/
[1] https://lwn.net/ml/python-dev/491cf94d-7887-407e-926f-c92081717dd5@www.fastmail.com
Python 2.7.18, the end of an era
Does this mean that Tauthon should now be considered the Python2 upstream? Or has that project also stopped making releases?
Python 2.7.18, the end of an era
Does this mean that Tauthon should now be considered the Python2 upstream? Or has that project also stopped making releases?
Python 2.7.18, the end of an era
No - it means that Python 2 has gone from being deprecated, to formally unsupported with a death date of 2020/1/1 to a final bug fix release which this is (and which was shown as such in the announcements round 2020/1/1. It's not just moribund or deprecated, it no longer exists.
No other project should be a new upstream because it's a good idea to carry on. It's _dead_ Here, it survives only in one case - the bookcase.
This has been a long time coming: it's been signalled for a very long time. Most distributions are now working to remove the final Python 2 packages, in some instances to replace them with Python 3, in others to just drop any Python 2 remaining. You might have to fudge the issue with a "system python" which is Python 2 internally: Red Hat will, potentially, have to support Python 2 until 2024 internally
I'm an engineer, not a doctor but "it's dead, Jim"
Python 2.7.18, the end of an era
No - it means that Python 2 has gone from being deprecated, to formally unsupported with a death date of 2020/1/1 to a final bug fix release which this is (and which was shown as such in the announcements round 2020/1/1. It's not just moribund or deprecated, it no longer exists.
No other project should be a new upstream because it's a good idea to carry on. It's _dead_ Here, it survives only in one case - the bookcase.
This has been a long time coming: it's been signalled for a very long time. Most distributions are now working to remove the final Python 2 packages, in some instances to replace them with Python 3, in others to just drop any Python 2 remaining. You might have to fudge the issue with a "system python" which is Python 2 internally: Red Hat will, potentially, have to support Python 2 until 2024 internally
I'm an engineer, not a doctor but "it's dead, Jim"
Python 2.7.18, the end of an era
> It's _dead_
No, it's not. There are many million-line projects still relying on Python 2.7
It will also be supported in RHEL until at least 2027.
Python 2.7.18, the end of an era
> It's _dead_
No, it's not. There are many million-line projects still relying on Python 2.7
It will also be supported in RHEL until at least 2027.
Python 2.7.18, the end of an era
Windows XP is not dead, there are millions systems out there ...
Python 2.7.18, the end of an era
Windows XP is not dead, there are millions systems out there ...
Python 2.7.18, the end of an era
Embedded versions of WinXP were supported up until January of 2019. That's 17 years.
Python 2.7.18, the end of an era
Embedded versions of WinXP were supported up until January of 2019. That's 17 years.
Python 2.7.18, the end of an era
Red Hat acknowledge the transition to communtiy support and no upstream with effect from 2020/1/1
The canonical link is here: [1]https://access.redhat.com/solutions/4455511
Red Hat 7.7 usage of Python 2 will not be extended: feature updates closed with 7.7
Red Hat 8 supports Python 2.7 in its application stream: this support will not transition to extended support so ends at approximately the same time.
All support does remain at Red Hat's discretion, ultimately.
I'd imagine the situation is broadly similar for SuSE Enterprise versions.
If you really, really want Python 2 code to work anywhere else, the answer is to port it to Python 3 - it's blunt, but everyone has had fullest notice since the first Python end date was planned for 2015.
[1] https://access.redhat.com/solutions/4455511
Python 2.7.18, the end of an era
> If you really, really want Python 2 code to work anywhere else, the answer is to port it to Python 3
Except to Go or Java, not Python 3.
Python 2.7.18, the end of an era
> If you really, really want Python 2 code to work anywhere else, the answer is to port it to Python 3
Except to Go or Java, not Python 3.
Python 2.7.18, the end of an era
Sad thing is -- as a recent LWN article explored -- for some use cases Py3 isn't great. I personally have a codebase or two pending a port to Py3 and the are few upsides to it, other than support.
Most of my codebases are web-based, and can safely assume utf-8, so all the unicode/utf-8 issues I might have to deal with are actual upgrades. Except, I've dealt with them already. Starting with Py3 would have sidestepped them, but that's neither here nor there.
A bunch of command-line utilities I have have been assuming filenames are a bag'o'bytes, as Linux and git do. They deal with inputs I do not control at all. Python 3 will result in loss of robustness. (Is there a clear path forward for dealing with this?)
One area I'm keen to find out whether it works well is async PostgreSQL. If asyncpg works reliably, I might be able to retire some NodeJS code I had to write just because Python couldn't do it.
Python 2.7.18, the end of an era
Or consider a bunch of build-related scripts in Chromium. Using python3 just slow downs already very slow build system as Python2 still starts faster than Python3.
I suspect the code will be eventually converted to Node and Go, not Python3.
Python 2.7.18, the end of an era
Or consider a bunch of build-related scripts in Chromium. Using python3 just slow downs already very slow build system as Python2 still starts faster than Python3.
I suspect the code will be eventually converted to Node and Go, not Python3.
Python 2.7.18, the end of an era
I'm curious, has *anyone* looked at building a compatibility layer for Python 2 as a module adapter for Python 3, such that you can intermix the two in the same program?
Python 2.7.18, the end of an era
You can't with CPython. PyPy apparently can, though I've not tried. Any C extensions are in one or the other because `libpython2.7` uses the same symbol names as `libpython3.x`. Plus, there's only one `PYTHONPATH`, so good luck getting each version to not grab from the wrong set of directories.
Python 2.7.18, the end of an era
You can't with CPython. PyPy apparently can, though I've not tried. Any C extensions are in one or the other because `libpython2.7` uses the same symbol names as `libpython3.x`. Plus, there's only one `PYTHONPATH`, so good luck getting each version to not grab from the wrong set of directories.