Python 3.13 Alpha Kicks Off The Cycle With New Deprecations

[Weasel]

What? You want it to never get rid of dated methods and modules and that it keeps growing forever, maintaining old stuff forever ?

Yes.

Are some point, there is a need for clean up.

No, there is not.

With your own code, I bet you remove old crumbs too, so why blame others about that same thing ?

I do if I can be bothered and am actively working on it (not a old, forgotten project that "just works"), but it's not my code.

I expect that code to still work when i upgrade Python.

Instead I have to keep multiple Python versions around just in case newer one breaks something. This stupid ideology is also the reason virtual environments in Python store the Python executables which wouldn't be needed if they promised perpetual compatibility. How is that less cruft?

Keeping multiple versions around and storing the executables in virtual environments is MUCH more baggage, bloat and crap, than keeping some deprecated methods around. You're literally duplicating the entire Python ecosystem of a specific version. Holy shit.

[Weasel]

Python 3.12 already breaks the Firefox compile process and now they want to drop even more stuff in 3.13.

YES. FINALLY SOMEONE WHO GETS an actual real life example. Firefox (and its forks) was one of the examples I had in mind since I compile them for various reasons.

[nanonyme]

YES. FINALLY SOMEONE WHO GETS an actual real life example. Firefox (and its forks) was one of the examples I had in mind since I compile them for various reasons.

To be fair, majority of the issues happen because app developers have been trying to support Python 2. If app developers had simply embraced Python 3 when Python 2 was going EOL, then we would not be here with these problems.

[dekernel]

If you're going to complain about something, at least be right about it. Python does not follow semantic versioning. If they were, it would be "Python 3, the language", version 13.0; Treat the minor/patch numbers as major/minor.

Even in the "old days", "semantic versioning" wasn't followed. The whole idea of "semantic versioning" was codifying what people sometimes did. Breaking changes in minor and patch releases still frequently happened.

And when such a major project doesn't follow the semantic versioning rules, it is an indication that the project is not run by professionals. Following the very basic rules of semantic versioning provides solid confidence to the user base that small updates will NOT break things which should NEVER happen in such projects. Your explanation is perfect explanation of just what the versioning process tells the outside world. Yes, sometimes minor updates would break things, but those offenders where typically told to "fix their crap and don't let it happen again". Just my $0.02 from this old guy because that process has served me well for years and years with no issues. Please do me a favor and don't point to the Linux kernel development as a good example of why semantic versions is not needed because it isn't.