News for hackers. Stuff that matters.
Re:Python 2.7.18, the last release of Python 2 by philwelch on Tuesday April 21, 2020 @12:25AM (#22931853)
> There's so much whining, when they gave over 5 years to do the migration.

You make it sound so generous of the Python maintainers to "give over five years" before breaking backwards compatibility--something that C, Java, JavaScript, C++, and probably most other languages haven't done for decades, or in some cases ever. Programming languages are serious basic infrastructure, programmer time is valuable, and Python's installed base is large enough that many man-centuries were probably wasted on this migration.

If the Python maintainers had not given as much time as they did, I doubt the Python community or ecosystem would have transitioned any more quickly than they did. More likely would have been some fork or alternate implementation of Python 2 becoming the new standard.

Re:Python 2.7.18, the last release of Python 2 by kerkeslager on Tuesday April 21, 2020 @01:18AM (#22932205)
Okay, but how many man-centuries have we spent fixing buffer overflows in C because the type system can't check that without breaking reverse compatibility?

Reverse compatibility isn't free.

Re:Python 2.7.18, the last release of Python 2 by philwelch on Tuesday April 21, 2020 @01:57PM (#22937482)
It’s not like C is the only programming language to have never broken backwards compatibility, or that conflating byte arrays and strings is as dangerous as buffer overflow.
Re:Python 2.7.18, the last release of Python 2 by kerkeslager on Wednesday April 22, 2020 @04:13AM (#22943321)
You're right, but it's the oldest that you mentioned, which is why it has the most serious signs of age. C originated 50 years ago: give Python 50 years of development without breaking any backwards compatibility and you'd have a programming language with many of the same kinds of problems.
Re:Python 2.7.18, the last release of Python 2 by musicale on Tuesday April 21, 2020 @08:06AM (#22934156)
People have made memory-safe compilers for ANSI C (e.g. Fail-Safe C.)

Unfortunately clang and gcc don't (yet?) have --safe or an x86-64-safe compilation target.

Re:Python 2.7.18, the last release of Python 2 by kerkeslager on Tuesday April 21, 2020 @09:08AM (#22934596)
Yes, but without major semantic changes to the language to go the direction of i.e. Rust, you're relying on bounds checking to make it memory safe. If you're using C for performance reasons, adding bounds checking is a break in reverse compatibility, because it happens at run time and drastically degrades performance in some cases.