Is it reasonable to propose incompatible changes to Python?
In general, no. There are already millions of lines of Python code around the world, so any change in the language that invalidates more than a very small fraction of existing programs has to be frowned upon. Even if you can provide a conversion program, there’s still the problem of updating all documentation; many books have been written about Python, and we don’t want to invalidate them all at a single stroke. Providing a gradual upgrade path is necessary if a feature has to be changed. PEP 5 describes the procedure followed for introducing backward-incompatible changes while minimizing disruption for users.
In general, no. There are already millions of lines of Python code around the world, so any change in the language that invalidates more than a very small fraction of existing programs has to be frowned upon. Even if you can provide a conversion program, there still is the problem of updating all documentation; many books have been written about Python, and we don’t want to invalidate them all at a single stroke. If a feature really has to be changed, it’s important to provide a gradual upgrade path if at all possible, usually spanning over multiple Python releases. In general, if a piece of Python code runs under release 2.X, it may produce warnings under 2.(X+1), but it shouldn’t break before 2.(X+2), at the earliest. PEP 5 describes the procedure followed for introducing backward-incompatible changes while minimizing disruption for users.
