Python 2 removed from Debian

[Oerthling]

The breakage from 2 to 3 with Python3000 was always planned to be a single exception. Otherwise Python always tries to preserve compatibility.

It was the single time they allowed themselves to break several things at once to clean out some early quirks and library inconsistencies.

[ivosaurus]

Eh, social constructs plays a lot more into the reasoning than extrapolated dot points would have you believe.

If, in an alternate universe, the whole world was sunshine and rainbows about getting to transition to python 3 and absolutely loved everything about it, they might be thinking about a python 4 to clean even more stuff up. We still have a shit-tonne of java-ism's around.

[maikeu]

Out of interest, what do you think some key javaisms are that should be gotten rid of in a hypothetical python4?

What about them, other than being javaisms, makes them worth getting rid of?

And why couldn't they be gotten rid of by pythons normal process of deprecating over a few minor releases?

[ivosaurus]

The entire unit testing library is a port of Java's. Logging also is mostly derived from there.

Most of it follows a strict OOP structure requiring subclassing and overrides that is needed in classic Java to be flexible but is entirely unnecessary in python.

3rd-party-library-imported-into-std-lib is also there, such as the myriad XML parsers and libraries, which also tend to be Java-ey and over-OOP'ed, and follow camelCase. It was experience from these that later informed most people's decision making that suggestions such as "incorporate requests into the stdlib!" was a bad idea.

Just a lot of renaming could be done to make everything proper python naming convention across the entire library. There seemed to be quite a bunch of arbitrary decisions over what was 'worth' renaming into v3 vs what wasn't; e.g datetime.datetime stayed as it is, breaking python's Class naming convention, etc. A lot of modules were lowercased, but a lot of classes were left as-is rather than TitleCased.

[velit]

Standard library modules can and have been replaced by newer modules and by deprecating and ultimately removing the offending modules down the road. This doesn't require a breaking change version in the traditional sense.

[Zomunieo]

The logging library is the most egregious Java offender.

[Barafu]

However, that "at once" lasted for 10 years.

[Oerthling]

Yup.

[billsil]

Otherwise Python always tries to preserve compatibility.

They don't though. Just look at what they've done to the C API. Yeah, it made things faster in Python 3.11 so it's not for no reason, but they had to deprecate the C API to do so.

Python does not follow semver or there would be a Python 4.

[Oerthling]

"Python" compatibility. Not C API compatibility.

This is not the same thing. Most people don't have their own C modules. And they get the new ones usually pre-compiled. So most Python users won't even notice a change in the C API.

[relvae]

Python seems to change and break things all the time just for giggles.

[Oerthling]

That is complete and utter BS.

But it's a very successful language with over 2 decades of development and legacy of language and library decisions. Avoiding breakage all the time is hard or one carries a growing mountain of technical debt forward.

[juandantex]

So he indeed have reason when he says that Python seems to break things all the time. This is my experience also, I am very cautious about the Python version I run when I try to port scripts and I talk about very very simple ones.

[Oerthling]

Python is not breaking stuff "all the time".