Thats not really fair. Python 3.2 was release in 2011 and Python 3.4 in 2014. Only 3.3 was released in the middle, I would not say it is only "so often" compared to c++. To be more general, C++ had 3 major versions from 2011 to 2017, while python had 5. Its more, but not significantly so (especially since very little compatibility is broken between 3.4 and 3.5 for example).

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.

But the compiler is the same, so you specify the dialect you expect to use rather than running a different binary. Although to be fair, at least one distro decided to start shipping gcc like gcc-X where X is the version, so you can have multiple GCC's installed. I'm not sure that was the best idea, but its what they did.

> Maybe Python should stop changing so often?

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.