AWS to cut Python 2.7 off at the knees in July with 'minor version update' for Chalice Amazon is the latest to drive a knife into the twitching corpse of Python 2 with an announcement that AWS Chalice will follow Lambda in nudging customers to later versions. 15 July is the cut-off date, which is generous considering the Python Software Foundation pulled the plug on fixes and support for Python 2 on 1 January …
What other languages have enforced such breaking changes? When I look at 30+ year old languages like C, C++, Ada, VHDL, COBOL, FORTRAN, etc. they somehow managed to get refinements and new features continuously over that time period, without abandoning existing codebases, and forcing developers to port over big stacks of code.
Heck, one can still compile pre-ANSI (<1989, K&R) C today in any modern compiler. Had to do that recently with the Dhrystone benchmark, for which the code predates ANSI C. Integrates fine in a C++17 codebase, too.
From my perspective as a developer - whose admittedly main Python experience exists out of porting Python code to C++ and debugging Python-based build systems - Python's decision to stab 20 years of Python codebases in the back was an exceedingly poor one, which may take at least another decade to get somewhat over.
Python has a history of changes, some of which are backwards incompatible: dropping support for backticks, demoting filter and reduce, etc.
While the move to Python 3 was very poorly handled, the ideas behind it were reasonable and generally approved. Code that runs on Python 2.7 will run on Python 3 with a minimum of changes, this was the reason for supporting 2.7 for so long.
But that battle is largely over now and new ones are starting, particuarly the one to force type annotations onto everything.
"Python's decision to stab 20 years of Python codebases in the back was an exceedingly poor one, which may take at least another decade to get somewhat over."
^^^^
This
As a 25+ year C/C++ developer on everything from 8-bit micros to Enterpise software, I can't imagine rewriting substantial amounts of code everytime the C++ standard is updated. (Although lately MS is trying its best to break shit from VS2019 update - to update). Java seemed to get it (backwards compatibility) right, at least for a while
I suspect one or more of the following is true of the Python deities that decide such things:
1) They aren't involved in large scale project development where 100000 LOC and 100's of developers are working on a project
2) They aren't involved in projects where the code life is expected to span 5,10 or even 20 years
3) They are lazy because it's much more difficult to add / fix functionality w/o breaking backwards compatibility than it is to keep APIs. I know this because I just finished spending 2 months on fixing an issue w/o API changes to a library, when it would have taken me 1 day if I had made a change to an existing API. This would have forced a relink / recompile of the library by the mulitude of applications that rely on it (yes, my paying customers appreciated this).
4) They aren't involved with developing software that runs on FDA (medical) equipment, where a single change can force the requalifying of the entire software chain that can take months of testing and cost $$$$
I actually don't have much respect for any programming language that relies on non-printable characters to format source code for successful compiling of it.
I usually allow one mulligan (redo) for major version changes, the real question is what will python 4.x be - will it break compatiblity with 3.x? Hopefully the language designers learn from their mistakes.
This idea that all code, everywhere, has to be rewritten every time a spec changes is just lunacy, IMO.
I Know.... ;TLDR
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
