The Python language does not generally provide backward compatibility. The ability to break inefficiencies and fix wrong design choices are major reasons why Python has remained lean and efficient over the last decades. However, the PEP 387 standard discusses that incompatibility issues should be well thought out.
Here’s the basic policy when backward incompatibilities may be introduced for the benefit of the programming language’s effectiveness:
- The change should have a large benefit to breakage ratio, i.e., a relatively high benefit and a low probability of breaking old code.
- The change that leads to incompatiblity should be easy to fix.
- The change should not lead to a semantic change of a given API because those type of changes are extremely hard to find.
- An exception to the previous rule is if one goes over a two-year depreciation period.
These rules are not 100% fixed—for example, the steering council can grant exceptions to those.
Here are two quotes regarding Python’s policy to backward compatibility:
“To remain relevant and useful, Python has to evolve frequently; some enhancements require incompatible changes.” — Victor Stinner
“I don’t believe that the way for Python to remain relevant and useful for the next 10 years is to cease all language evolution. Who knows what the computing landscape will look like in 5 years, let alone 10? Something as arbitrary as a 10-year moratorium is (again, IMHO) a death sentence for the language.” — Barry Warsaw
In summary: the policy for Python version backward compatibility is that it should be avoided if possible but is not guaranteed.