Re: Legacy code's legacy
"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."
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