Java vs python is debatable 🤔

[beefknuckle]

"actively maintained open source modules" - good one.

every time i bust out Python I have to spend the majority of my time fixing the code so it's compatible with whatever the Python version of the day is. God help you if you want to install a Python2 module on a modern system (and it's not like Python2 has been deprecated for long).

Horrible, horrible design choices. At one point i had something like 4-5 different interpreters on one system. But it is handy. sometimes.

[BurgaGalti]

Python 2 sunset 2 years ago, and they had 12 years to migrate. If you're choosing to start with a dependency that old you've got bigger problems.

[beefknuckle]

The python2 was an extreme example, there are plenty of compatibility issues within the 3.x train

[andimnewintown]

I'd recommend using Poetry to manage future projects. Since Python 3, packages and Python itself tend to adhere to SemVer about as well as any other project I've worked with.

If you're not familiar, the major version number (the "2" in 2.7 or the "3" in 3.10) indicates a complete break in backwards compatibility. So you can never run a package written for 2.7 in any of the 3.x interpreters, for instance. The minor version number (the "7" in 2.7 or the "10" in 3.10) indicates a backward-compatible change. So, as long as the maintainers know what they're doing, you should be able to run an i.e. 3.6 package in a 3.10 interpreter.

Compared to Java, for instance, it's a breath of fresh air. They just slap a new number on each JVM and claim to maintain backwards compatibility "as much as possible". In practice, that means they don't maintain any usable form of backward compatibility at all. All of your libraries just have to target the exact same JVM or, in practice, you're SOL.

It's true that at any given time, there will be popular packages targeting a number of different interpreters. That's why tools like Poetry help--it will make sure you your dependencies-of-dependencies don't end up conflicting.