> In the unittest module, a number of long deprecated methods and classes were removed. (They had been deprecated since Python 3.1 or 3.2).
I doubt your projects are using 3.1 or 3.2 (or older, except perhaps 2.7, but then you wouldn't care that 3.12 was removing something deprecated vs 3.11 which has it)?
https://docs.python.org/dev/whatsnew/3.12.html#removed
An example of a more recent deprecation is the 'distutils' module which was deprecated in 3.10.
distutils was functionally deprecated long before that. Even the Python 2.7 documentation (released in 2010!) recommended that users avoid distutils and use setuptools instead: https://docs.python.org/2.7/library/distutils.html
Last I checked, there was no good way to package hand-written Python/C extensions than setuptools, but that was a couple of years ago.
In any case, there's a large installed-based of setuptools-based projects making it hard to get rid of.
Nevertheless, there is no doubt that it is the worst software project that I have ever seen, during several decades, from the point of view of keeping compatibility between versions.
For other programs, I may happen to need to have installed 2 versions, or maybe 3 versions, at most, in order to be able to use other programs that are compatible only with certain versions.
On the other hand, for Python, during many, many years, I have been forced to keep installed all the time around 7 or 8 versions, to keep happy many other programs that claim to be compatible only with certain Python versions (and not also with any newer versions; some programs are even compatible only with a list of non-consecutive versions).
Building from source any program that depends on Python may frequently require various temporary configuration modifications, to ensure that the program is built only for the Python versions with which it is compatible.
I love writing Python code. I love its standard library and many third party libraries. But I loathe Python’s dependency management, and Python version upgrades are sometimes a huge pain. There are tools to help with this (pyenv or I am fond of asdf for python versions; poetry or pipenv for isolating package dependencies), but they only partially solve the problems and introduce new ones.
> to express disapproval of
> to withdraw official support for or discourage the use of (something, such as a software product) in favor of a newer or better alternative
In other words, deprecated is a strong signal that one should strive to migrate from items marked as such.
Compared to that, Java still carries some deprecated items around. But with Java 9, deprecation for removal was introduced, which is a strong signal that stuff will be gone in two releases. Kubernetes has a strict deprecation policy as well, such that skipping more than two releases is asking for trouble.
But the Python community fear major version changes. So the minor versions become major versions.
Now there will be an endless churn to keep programs up to date for "security reasons" and that cost money.
We can even pull the plug on programs nowadays to the give the users the very best experience! Otherwise the lusers might have felt satisfied with what they have.
Ye I am whining but only half joking.
Breaking backwards compatibility ruins my mood. And Python are getting way to much slack for what they have been doing to the users.
People wanting to stick to 2.7 are ridiculed and soon the software security police will start arresting offenders.
Using 2to3, the most trouble I had were db migrations, which I just squashed. The rest were ferreting out str() problems that 2to3 didn't find (eg. redis package happily taking strings but returning bytes by default), Django regexp url changes, and trivial stuff like that.
It took a couple of days work.
I also wanted to upgrade the frontend part (webpack build of Vue). I stopped after a few hours od going nowhere and am still apprehensive of approaching that particular thing.