The title is referencing this line (not TFA's actual title):

> 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)?

I do not know what is wrong with Python, because I use it only occasionally, for short programs that do not use obscure features.

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 will say this, I love python, and I hate python the way only someone who loves it can. I think everything you said is accurate.

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.

There's quite a bit more than just the unittest removals

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.

> 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

Isn't setuptools deprecated now too or on the chopping block?

I believe setuptools is more frowned upon - in favor of PEP 517/PEP 518 tools - than deprecated.

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.

Deprecated does not mean removed. They are still there, working fine, having no big reason to change them. I know it, as I just checked my and my workplaces code, and there are several usages of deprecated code. And we are on 3.9/3.10.

Merriam Webster lists the following relevant meanings for "deprecated":

> 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.

So what? As long as it works, don't change it. This parts are deprecated since up to nearly a decade (Python 3.2 was released February 20th, 2011). And they will work for some more years. Some have not even a working replacement yet. Investing now in changing old code just to be compatible to a not even released version, is a bit pointless if you have more important work on the list.

Python 2 was supported for way longer than initially announced. Distutils as well. Maybe deprecated is not a strong enough signal because many projects hesitate to cut stuff loose that they deprecated because of the community backslash. Sometimes things have to be deprecated, but the community will never get around to adapt to that if they stick around forever.

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.

Except the notice is about "removing deprecated modules"? Deprecation usually means "These are going away at some point. Be aware.".

It should mean 'next major version'.

But the Python community fear major version changes. So the minor versions become major versions.

The move to web based apps or connected in general was a genius move by the programming community.

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.

Actually this is a return to the past, we used to call them timesharing systems.

You say that, but the web platform rarely if ever removes features in this way. My web code from 15 years ago works the same as it always did.

Obviously you chose the wrong framework or even worse - none at all.

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.

I recently upgraded a Python 2 + Django 1.x project with no tests to Python 3 and latest Django.

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.

If people that want to stick to 2.7 can find a vendor that supplies them security patches, then there is no problem.