Well, you'd think after the 2 to 3 debacle, python might take backwards compatibility more seriously, but they don't.
Follow semver, and stop breaking things on 3.x. If it's deprecated in 3.x, don't remove it until 4.
PEP387 requires that introduced incompatibilities have a “large benefit to breakage ratio,” and that any deprecations last a minimum of two years.
FWIW, Kubernetes has a similar approach. Breaking changes occur all the time with “minor” version updates.
E.g. Python 3.12 has deprecated datetime.utcnow(). So it will probably be removed in Python 3.14 or 3.15.
For all intents and purposes, "Python 3" is now the brand and "Python 3.x" releases are major, breaking releases.
Clojure is pretty good even on that timescale though.
[1] See eg https://stackoverflow.com/a/50445603 up until 2021
In some environments, yes. A bunch of platforms have started using bash-compatible (but not actually bash) shells like fish to help with startup performance. Apple has upgraded from a truly ancient version of bash to a somewhat-modern one in that time (and then gone all-in on zsh instead). Things change on the scale of a decade.
Yes, of course, things do change incompatibly in a decade, probably including some of the nonstandard platform-specific commands called by the script regardless of which dialect of shell. But people who use a nonstandard shell dialect - however common it might be at the time of writing - should be prepared for that shell to become uncommon, absent by default, installed at a different path, incompatibly changed, or otherwise unusable a decade later to an extent that people writing to the standard do not.
It's harder to upgrade services in a central way with any amount of leverage, and generally requires more coordination overhead, and moving more carefully.
Compare with, say, golang, where it's pretty much a non-issue. My experience with Ruby was a lot better too, until Ruby 3, but hey, that was a major version bump!
People who have Python 3 installed can be on many different versions. The thing is, depending on the version, quite often bug fixes included in later versions aren't in older versions. So if you want to make your code work -- got to get the patches in manually, monkey patch broken code, and do it that way. Then there's the seemingly random deprecation of standard library modules / other breaking changes.
I take python version support seriously because if people install your packages you'll be outsourcing all of the above crap to the user. They might not even know how to 'upgrade' python. Or end up on the wrong version. If your package doesn't work when they install it they'll just move on to something else. Python is a total shit show for packaging.
Doing development on the projects without a specialised build environment, though, is almost hopeless. You either have to manually install a bunch of stuff (e.g. I use ruff, used to use ruff and black, used pre-commit, and a few other things), and then there's the non-Python things that need to be installed (like specific fonts in my case). At this point I just impose Poetry as basically a requirement for development.
The program does build and function in a non-Poetry environment which is what I use for production.
Moving fast is really nice when you can get paid for shipping and have the project either be retired or someone else’s problem in a decade.
Most places don't have the resources to keep updating everything for little benefit. (just look at node its terrible to support. )