With C++ for example you are usually either targeting C++11, C++14, or C++17 (or if you're really unfortunate, C++03). The set of features in the language only changes every few years.
Granted it's still possible that someone could have an old compiler that doesn't implement the advertised standard correctly, but that's a bug, not a deliberate design choice.
And if you are talking about which version is shipped with a distro, then RHEL7 ships with gcc 4.8, which support only parts of c++14, while for example the latest Ubuntu LTS ships GCC 7,3, meaning you get full C++17 support.
Don't get me wrong, the Python packaging situation is not very clean. But it is far from being an exception, and people complaining about it are just spreading FUD.
This argument is almost cyclical.
> With C++ for example you are usually either targeting C++11, C++14, or C++17 (or if you're really unfortunate, C++03). The set of features in the language only changes every few years.
C++ went from glacial-pace changes - 85 / 98 / 03 / 11 -- to much faster ones: 14, 17, 20. This change in standards behavior was motivated by closing the gap with feature-rich, faster-moving languages like Python (Java, C#, etc).
Python makes language changes somewhat rarely, but library changes more often. The majority of the time, those library changes are brand new functionality.
Also, FFS, why can’t pyc files have a bytecode format version number embedded in them, or at least be called .pyc3 by python 3?
The whole ecosystem needs to solve the packaging problem, or get replaced by some other language ASAP. Instead, it’s breaking entire distros with its packaging tire fire.
For many python projects I’ve dealt with, it is easier to reimplement that dang thing in some other language than make the python build reliable, secure and redistributable.