Python 2's Core Devs Say 'Fond Farewell' While Releasing Its Final Version (blogspot.com) 97
This week Python's core developer blog announced the very last production release of Python 2.7. Hackaday reports:
The intention was for it to coincide with PyCon 2020, but just like so many of the events planned for the first half of the year, the in-person conference had to be canceled in favor of a virtual one due to the COVID-19 epidemic. That might have stymied the celebration somewhat, but the release of Python 2.7.18 will still be looked on as a special moment for everyone involved.
"Thank you @gutworth for being the 2.7 release manager during 11 long years," Guido van Rossum announced on Twitter.
"It's time for the CPython community to say a fond but firm farewell to Python 2," reads the announcement on the core developer's blog. 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.
Python 3 would be nowhere without the dedication of the wider community. Library maintainers followed CPython by maintaining Python 2 support for many years butalso threw their weight behind the Python 3 statement. 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+!
"Thank you @gutworth for being the 2.7 release manager during 11 long years," Guido van Rossum announced on Twitter.
"It's time for the CPython community to say a fond but firm farewell to Python 2," reads the announcement on the core developer's blog. 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.
Python 3 would be nowhere without the dedication of the wider community. Library maintainers followed CPython by maintaining Python 2 support for many years butalso threw their weight behind the Python 3 statement. 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+!
No they don't. (Score:3, Insightful)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re:No they don't. (Score:5, Insightful)
We will be waiting for the death of Python2 just as painfully as we waited for the release of Duke Nukem Forever.
And this is why people are prepared to deal with the crap in C++ from it's long and storied history. Sure, ossified misfeatures from another era are annoying, but having to port your code when a new version comes out is even more annoying.
The python foundation might think python2 is dead, but it's going to be around for a very long time. Anyone with paying customers (e.g. Maya, RHEL, etc) are going to keep not giving their customers a reason to look at a competitor (breaking compatibility). And there are useful libraries out there from the 2 era which were finished and the author moved on.
this split is going to be around for a while.
Re: (Score:1)
Re: No they don't. (Score:1)
Iâ(TM)m curious about said disaster(s), as I recently started with Python 3 and find it interesting.
Re: (Score:2)
Run while you still can.
We're terrible at learning from history. (Score:1)
I expect screams and wails from Python 3 developers when Python 4 or 5 takes off.
Re: (Score:1)
Re: (Score:2)
Re: (Score:2)
If you just make use of the core functionality and the built-in libraries, it more than likely won't be a big deal. 95%+ of it probably will have to do with the stupidity of getting rid of the "print" keyword in Python 3*. If you had to do a bunch of hacks to support unicode though, it can turn into a hairy mess.
If you use various libraries, you can be in for a bit of fun, as so many Python libraries don't have a stable API, and even more so between Python 2 and Python 3, and that assumes your Python 2 li
Re: No they don't. (Score:1)
When you're talking about porting 10,000 lines in a small program or library, you're still talking 100 lines strewn throughout.
The libraries are the biggest problem. Things like SQLAlchemy and Flask for example require significant changes and return entirely different types in some cases (or Python2 correctly inferred types and Python3 doesn't). For example an LDAP query in Python 2 returns a string, in Python 3 returns byte string which isn't always easy to simply cast to string. Same goes for JSON being a
Re: (Score:3)
Re: (Score:3)
It's not. Stuff on Intels c compiler can't be ported msvc to run better on AMD chips and at work we have VS2017 code that won't compile in vs2019.
Java is a clusterfuck too which is why java7 is still the standard
Re: (Score:2)
It's not. Stuff on Intels c compiler can't be ported msvc to run better on AMD chips and at work we have VS2017 code that won't compile in vs2019.
Yes if you use specific vendor's specific compiler's extension then yes the C++ standard won't guarantee portability and stability of things that aren't in the standard. How on earth is this a surprise? If you want the guarantees of the C++ standard, then you actually need to write C++.
Consult your compiler's manual to see how to switch it into a more pedantic com
Re: (Score:2)
Explain why my employer has vs 2017 code that won't compile in vs 2019?
Re: (Score:1)
If you can't port from VS compiler to VS compiler, it probably means you happened to hit some areas where there was some ambiguity in the standard where it's now better defined. And even then, I'll bet there are compatibility flags that preserve the old behavior, if you checked.
There are LOTS of counter-examples that demonstrate it's perfectly possible to write very portable C++ with a bit of effort. To do this, you tell your compiler to adhere to strict standards compliance, turn your warning levels up a
Re: (Score:2)
Explain why my employer has vs 2017 code that won't compile in vs 2019?
You didn't write standards compliant C++, you used some extensions or permissiveness specific to a single vendor's compiler and the compiler vendor changed they behaviour.
Re: (Score:2)
We do and our senior engineers are quite competent. They only hire people with 10 years of experience in C++, node.js, and other technologies they use in their stack.
Basically it is the optimizations that occur that are incompatible at the assembler end with all the flags, not the language syntax.
My point is C++ is not a one all standard that is multi-platform otherwise Java never would have been written. The code they work on is run on embedded systems so I doubt they use Windows Specific optimizations.
Re: (Score:2)
We do
Overwhelmingly likely is you had UB and didn't realise it. The second, very distantly likely option is you found a compiler bug. The chance you had compliant code which broke from is very, very small.
The thing is the standard will tell you what the behaviour was, so if you can point me to where the 14 and 17 standards changed behaviour, then it was compliant code. If you can't then it was a bug on your end (o maybe the compiler, but it wasn't the compiler).
our senior engineers are quite competent. They
Re:No they don't. (Score:4, Informative)
The python foundation might think python2 is dead, but it's going to be around for a very long time. Anyone with paying customers (e.g. Maya, RHEL, etc) are going to keep not giving their customers a reason to look at a competitor (breaking compatibility)
Autodesk employee here -- Python 3 in Maya and Shotgun is "coming soon" (I know when, not allowed to say), but yeah, you're right, we have a ton of big customers and partners who are sitting on large Python 2 code bases that run significant portions of their rendering pipeline. Breaking them isn't an option, especially mid-project. Most studio directors don't give two shits about the differences between Python 2 and 3 anyways, so why would they take the risk?
And sure, I get it, it's easy to blame Autodesk for holding things back at Python 2. But it's an industry-wide transition that's been slow to come. Pixar, for example, just finished porting their Universal Scene Description Python implementation to Python 3, like, in the last few weeks... and I think it still took someone at NVidia to actually provide a lot of the code.
Re: (Score:1)
And sure, I get it, it's easy to blame Autodesk for holding things back at Python 2.
I hate autodesk. While the can fuck off for buying Eaglecad and making it subscription based then fuck off even harder, this isn't on them. This is 100% the fault of the python foundation. It was entirely obvious this happens. Autodesk were (rightly) never going to screw over their customers because they wanted print() to have a slightly more regular syntax and for better Unicode handling in an industry that simply doesn't
Re: (Score:2)
Re: (Score:2)
They are coding Duke Nukem in the final release of Python 2 on a quantum computer running on fusion energy.
Re: (Score:2)
Upgrade you python 2 to 3. Usually isn’t too hard. A good portion of the code is the same. Some of the changes can be done with a search and replace.
This is no way like COBOL because it is the same language and uses the same coding styles.
Re: (Score:2)
The problem is the large depreciated libraries and apis. Newer ones are incompatible and will break existing code or don't exist at all.
Re: (Score:2)
Re: (Score:2)
Hence why I tend to yell at devs who include 3rd party API just to save an hour of coding.
The stuff that is included in the language, will normally be ported over to the next version, at worse with some minor tweaks. 3rd party tools you cannot trust if those devs give up on the project by the time the next minor upgrade happens, and will not be interested in maintaining it. As this library didn't get too popular, and the programmer life conditions changes where they cannot upgrade it anymore.
This isn't j
Re: (Score:2)
No, it's not like COBOL. There's code written in COBOL over half a century ago that can still be run today without any modifications. Good luck doing that with any version of Python for something that's non-trivial.
Actually, it wouldn't surprise me if the vast majority of the Python2 stuff will be dead in a few years, and not by choice. Once the libraries drop Python 2, library support starts disappearing, and pip stops supporting Python2 it could start getting tricky to get that old Python2 code running
Re: (Score:2)
The Python module incompatibility is a very important point, which I think many people don't really appreciate the implications of. No matter who maintains extended support for Python 2.7, the pypi module ecosystem will quickly become a broken mess as soon as even a small number of key modules drop compatibility with it. Old applications will repeatedly break, and the solution will be pinning dependencies. But that will only work for do long.
This isn't even a new thing. There's nothing special about Pyt
Re: (Score:2)
Java already is replacing COBOL
Re: (Score:1)
Python 3 is alright but still has a ways to go... (Score:5, Funny)
It's in RedHat / CentOS 8 (Score:3)
So we won't actually be bidding Python 2 a "fond farewell" for quite a few years.
Re:It's in RedHat / CentOS 8 (Score:5, Informative)
The bigger problem was that RHEL7 did not have Python 3. Python 3.3 was out over a year before their relase and 3.4 a few months before it, but they utterly ignored it. Until they decided to actually have it in RHEL8 and then added it to RHEL7.7 in some vague effort to have some bridge between RHEL7 and RHEL8 environments, where developers went from not having a core supported path to running python3, to all of a sudden being told they shouldn't be using python2 at all in a single leap.
It was a particularly messy way to handle the already messy 2 to 3 transition in general.
Re: (Score:2)
not a problem at all, most the big customers don't need or want python 3. They're not going to rewrite code that took a decade to build because some neckbeards like the "oooo shiny", that's why they pony up big money for distros that value stability and backward compatibility.
Re: (Score:2)
The problem being that they do need and want python 3, because there are articles out bemoaning that python 2 is entering unsupported state and that means security is going to just fall apart all of a sudden.
Sure, someone can point out the whole point of RHEL is to support technologies past when upstream says they are supported and thus not to sweat the python panic for now. However it is very hard to argue that all these articles about 'end of life' for python 2 can be ignored when the consequence of being
Re: (Score:2)
Wrong and wrong and wrong
Python 2 is supported by the big distros and will be for years. None of the big enterprises I know of using it want it (working with data analytics places, marketing demographics and banks). They aren't going to rewrite stuff every time the neckbeards have a brain fart.
Security? The stuff is middleware and backend, web app firewalls and next gen firewalls and other vlans of architecture in front of it. Not where the security breaches are going to happen, that's just FUD.
Re: (Score:3)
Hope your users are not financial institutions? That is a SOX audit fail right there and an insurance policy denial as well for using unsupported code.
Re: (Score:2)
Re: (Score:2)
There's a big gap in your consideration here.
Yes, the Python 2 interpreter is supported for quite a few more years. And the selected modules packaged for the system.
But, the wider ecosystem around it is most definitely not. pip install will break. You'll need to manually pin not only every dependency, but every transitive dependency. And while this will work for a time, the game is up the moment your hand is forced to update one of the modules, and you can no longer assemble a working set of modules. T
Re: (Score:2)
I should add to this that our eventual solution, at least for a time, was to require installation of a more recent Python version under /opt and use that in place of the system interpreter. For RHEL and CentOS, newer Python interpreters are available from several sources, e.g. SCL, so it is possible to do a managed update to a newer version which is also properly supported.
One last additional point, pip itself drops Python version support as well. So long as you don't update it, that won't cause many prob
Re: (Score:2)
That is horrible and inexcusable lazyness, or just a bad decision to a trade-off.
Yes porting costs money, it is a trade off between the short term and the long term.
Companies who make the wrong decision (go for short term 0.1% more profit) deserve to go bankrupt.
Re: (Score:3)
indeed, until 2024 anyway.
I wish the open source language makers would respect backwards compatibility. Python has become popular in enterprise use for data analytics, and the version 2 code base is massive, not easily rewritable. With many more traditional languages I can run code from decades ago in a modern supported compiler or interpreter.
Re:It's in RedHat / CentOS 8 (Score:4, Funny)
just looked, SLES 15 has both python 2 and 3 and will be supported until 31 July 2028.
hahaha, see you chumps in 8 years when your python 4 will have broken your python 3.
Re: (Score:2)
indeed, until 2024 anyway.
In addition, there'll be "maintenance support" for CentOS 8 though 2029 - followed by the option to pay for an additional two years of "extended life".
I'm totally with you regarding language backward compatibility. As you say, rewriting is not always straightforward... not to mention that many/most of us who get paid to write code aren't going to get a lot of support for projects where "I need to rewrite this system because the language is no longer supported". If I had any significant amount of python2 cod
Re: (Score:3)
That's because you don't understand how similar the two languages are to the end user.
The main change is that "print" is now a function rather than an internal, so you need to surround the arguments with "()".
Another change is that the syntax of the assert statement changed.
The more difficult case is with the alterations in string handling, but even so they aren't major, especially if your strings are limited to ascii-7.
The real problem is libraries that are no longer supported, and haven't been for a decad
Re: (Score:3)
Actually the biggest problem I ran into migrating to Python 3 is the change from list to generator for calls like keys() and items(). Places that use these functions as opposed to the iter*() variants do so intentionally. They need actual lists in order to modify them or read from it more than once. Fixing them isn't hard, just have to add list() around it, but unfortunately the errors are only surfaced when the code is executed.
Re: (Score:2)
Actually the biggest problem I ran into migrating to Python 3 is the change from list to generator for calls like keys() and items(). Places that use these functions as opposed to the iter*() variants do so intentionally. They need actual lists in order to modify them or read from it more than once. Fixing them isn't hard, just have to add list() around it, but unfortunately the errors are only surfaced when the code is executed.
Many of these problems wouldn't be so bad if one had decent test coverage. Not that I can talk as regards test coverage myself but a lot of complaints seem to be of the - "we have a lot of unmaintainable code, please don't force us to touch it" variety.
Re: (Score:2)
Porting to python 3 is less trivial than it looks, but it's not *too* bad. The real aggravation sets in trying to make sure your code works in both 3 and 2, as the most frequent answers revolve around jumping to the new way rather than some common vocabulary to support 2 and 3.
Re: (Score:2)
We do have test coverage, but we don't have 100% coverage, more like 80-90%. Unfortunately, 100% is what you need when the language pulls the rug out from under you. Then fixing the tests is yet another headache.
Re: (Score:2)
The string handling is particularly messy because even if you were just passing data from one core python library to another, they will now bail out.
One interesting example is base64 library, which in python3-ism takes a bytes and makes another bytes out of it. A coding explicity designed to make it easier to pass as 7-bit ascii clean strings will cause python string processing to throw up at you unless you then decode it from acsii or utf8, mainly because base64 'encode' is used elsewhere in the language
Re: (Score:3)
Python 2->3 has had the longest transition period in history, and still people are complaining about it?
Anyone who packaged python 2 in the last few years is to blame, not the pytohn OSS developers.
In 2007 I had to do a small job in python, I looked at python 2 vs 3 and decided it would make no sense to use a version that would be "obsolete soon".
Re: would make no sense (Score:3)
> In 2007 I had to do a small job in python
Yes, you had a small job, so you could get away with Python 3. In 2018 I had a medium-sized job to do, which would need to run on other developers' machines. Python 2 was part of the system installation on them, Python 3 wasn't, and some libraries had still not been ported. Some had been ported, but incompatibly (looking at you, unittest).
> Python 2->3 has had the longest transition period in history,
This isn't the end of the transition, it's the start
Re: (Score:2)
The version enterprise people install most is Red Hat 6, so no, we won't be bidding Python2 farewell in a while.
Re: (Score:2)
Why would people install 6, which is basically EOL'ed already and will even lose the option of paid extended in the near future? RHEL 6 was released in 2010.
Re: (Score:3)
10 years support. Companies still use IE 6 heavily too and at work we have Solaris 8. Linux just is too unstable and can't handle loads that Solaris 8 can
Re: (Score:2)
Thankfully I have not had to deal with one in a while, but 6 *really* hung in there. When actually bothered to give an explanation, it was generally uncertainty around this new fangled systemd that the internet kept talking about. In their defense, particularly before 7.2 systemd had particularly frustrating issues and early evaluators with any skepticism had plenty of evidence to vindicate themselves.
Basically 8 coming out seemed to be the move to make them decide that they need to deal with it eventually
Re: (Score:2)
Its retirement date is the 30th of November, so there is just six months to go.
Re: (Score:2)
systemd still sucks my ass, though.
Re: (Score:1)
I've got a customer asking for CentOS 7 support for their new expensive project. You can't really get away from old versions of software, someone that pays your bills is going to make you support old stuff that you wish you could drop.
Python 4? (Score:3)
Re: (Score:2)
Another breaking change is coming. We get to repeat this cycle again.
Python 4 breaks parts of 3 on purpose. They didn't learn their lesson. Eventually people will leave just like they did PHP and Perl.
Re: (Score:1)
If Python 4 didn't break Python 3, they'd just call it Python 3 with a bigger minor version number.
Re: (Score:2)
Re: (Score:2)
Funny have Microsoft and Sun/Oracle have managed to keep C# and Java mostly backward compatible all these years... it can be done better.
It's exactly as I said (Score:1)
Java 14 = Java 1.14
Java 5 was where they dropped the 1.x and just used x. (previously it was Java 1.4). If there is a Java 2.x, we can expect it to break everything. I doubt that will happen, not because I have faith in the engineering but because I have faith in the money behind that market.
Re: (Score:2)
I don't think they'll want to go through that again. But just in case they do, I propose the breaking change should force everyone to go from "print('Hello World')" back to "print 'Hello World'" again. It's not even that hard to implement, just define a new function call syntax that omits the parentheses.
Re: (Score:2)
Don't you mean Python 4000?
Re: (Score:2)
What? (Score:3)
The is a "Microsoft Visual C++ Compiler for Python 2.7"
Shiver me timbers! I thought Python was written in C and the Windows version was compiled using the crappy Microsoft Compilers. No idea why they chose to use the crappy non-standard Microsoft compilers, but they did.
I was unaware that there was a working compiler for Python 2.7, and I am shocked that Microsoft had/has anything to do with it.
Re:What? (Score:4, Informative)
For binary compatibility. It was using (IIRC) VS2008 or maybe 2010 originally. It's a while since I checked specifically. You can't use a newer version without introducing a compatibility break due to the different runtimes. These are way too old for contemporary Windows 10 systems, which is presumably why Microsoft kept the older compiler alive specifically for Python use.
You could have similar problems on Linux if you try to pip install packages on an non-glibc platform where the modules embeds Linux binaries using glibc-specific features. In fact, it's fraught with annoying ABI issues and versioning mismatches even on standard glibc due to the way Python module versioning works (or, rather, doesn't).
Re: (Score:2)
Oh, you are talking about a compiler for compiling the Python 2.7 interpreter, and not a compiler for Python. I have been using a "real compiler" to compile C code for Python 2.7 (GCC) and not that crappy Microsoft compiler. Works just fine. On Windows.
Re: (Score:2)
You can absolutely use other compilers to compile Python on Windows if you want to. The restriction is simply about guaranteeing ABI compatibility for the official python.org interpreter with any third-party modules for the entire lifetime of the minor version. If you're doing your own thing, then that guarantee isn't so important, but for other people it has been invaluable.
Re: (Score:2)
You know it's 2020 now right?
Better headline (Score:3)
This is why COBOL has lasted so long (Score:3)
Look Ma; no bit-rot. You can take a 30-year-old COBOL program and run it on a current compiler. Try running a 3-year-old python 2.x program on python 3.x and see how far you get..
Re: (Score:1)
Because they aren't selling a compiler for a language with a strong internal design concept; it's more that they're selling a standard library.
Re: (Score:2)
They've even removed things in 3.9 that only had their replacements added in 3.2: array.tobytes() was added in 3.2 to replace array.tostring() and they're removing array.tostring() in 3.9 - we're already having to work around breaking changes between minor versions of Python 3. They don't seem to understand stability at all.
Re: (Score:2)
"You can take a 30-year-old COBOL program and run it on a current compiler. "
A 30-year-old COBOL program was written when the language was 31 years old. Python is only 29 years old.
Why did they split? (Score:2)
Why did Python 2 and Python 3 split?
--
Question everything. Learn something. Answer nothing. - Euripides
Re: (Score:3)
I think the main reason was to deal properly with unicode strings. In Python3 strings became immutable and able to cope with unicode. (Actually Python 2 had a kludged way to handle unicode strings. At first I actually preferred it.)
The main problem with Python3 is the GIL (global interpreter lock) which makes concurrent execution difficult. The Multi-processing library is a way around it, but to me it seems an ungainly kludge. But getting people to agree on what the proper solution is is not easy. I,
Re: (Score:3)
You can't do something like "string[4] = 'x'" in either Python 2 or 3, but you can do "string += 'x'". So I don't think there is a change in mutability.
The big breaking change is this Unicode stuff. But they are idiots. There is VAST amounts of code that relies on a "string" being able to hold an arbitrary sequence of bytes. As soon as you read from an untrusted source you have arbitrary bytes. In Python2 you could put these into a string (it would do horribly stupid things if you attempted to print them, b
Re: (Score:2)
For mutable byte strings they want you to use byte arrays. Which are convertable to strings.
Re: (Score:3)
Yes that's true but I'm actually not very interested in mutable strings. What I want is to be able to read in *arbitrary* data, pass it to a function like "fopen" that expects a "string" and NOT HAVE IT BARF IF IT IS NOT UTF-8!!!!! Python and Qt are making this almost impossible with their idiotic use of UTF-16 and insistence on lossy and error-throwing conversions of bytes to "unicode".
There's a Python 3?!?! (Score:4, Funny)
Why python isn't appropriate for large projects (Score:2)
Its fine for small quick things, but for this, and other reasons, I don't think its a good tool for any large project. Building a website, or some sort of quick interactive program, great. Its good for that. It just becomes a problem when someone wants to use it for the control system of a large particle accelerator, or giant telescope project, or any large and long duration project.
Re: (Score:2)
Let this disaster be a lesson (Score:1)
Supporting compatible versions (Score:2)