Abstract

In the natural evolution of programming languages it is sometimesnecessary to make changes that modify the behavior of older programs.This PEP proposes a policy for implementing these changes in a mannerrespectful of the installed base of Python users.

Implementation Details

Implementation of this PEP requires the addition of a formal warningand deprecation facility that will be described in another proposal.

Scope

These guidelines apply to future versions of Python that introducebackward-incompatible behavior. Backward incompatible behavior is amajor deviation in Python interpretation from an earlier behaviordescribed in the standard Python documentation. Removal of a featurealso constitutes a change of behavior.

This PEP does not replace or preclude other compatibility strategiessuch as dynamic loading of backwards-compatible parsers. On the otherhand, if execution of “old code” requires a special switch or pragmathen that is indeed a change of behavior from the point of view of theuser and that change should be implemented according to theseguidelines.

In general, common sense must prevail in the implementation of theseguidelines. For instance changing “sys.copyright” does not constitutea backwards-incompatible change of behavior!

Steps For Introducing Backwards-Incompatible Features

1. Propose backwards-incompatible behavior in a PEP. The PEP mustinclude a section on backwards compatibility that describes indetail a plan to complete the remainder of these steps.
2. Once the PEP is accepted as a productive direction, implement analternate way to accomplish the task previously provided by thefeature that is being removed or changed. For instance if theaddition operator were scheduled for removal, a new version ofPython could implement an “add()” built-in function.
3. Formally deprecate the obsolete construct in the Pythondocumentation.
4. Add an optional warning mode to the parser that will inform userswhen the deprecated construct is used. In other words, allprograms that will behave differently in the future must triggerwarnings in this mode. Compile-time warnings are preferable toruntime warnings. The warning messages should steer people fromthe deprecated construct to the alternative construct.
5. There must be at least a one-year transition period between therelease of the transitional version of Python and the release ofthe backwards incompatible version. Users will have at least ayear to test their programs and migrate them from use of thedeprecated construct to the alternative one.