
PEP: XXX Title: Guidelines for introducing backwards incompatibilities Version: $Revision: 1.0 $ Author: Paul Prescod <paul@prescod.net,paulp@activestate.com> Status: Draft Type: Standards Track Python-Version: All Created: 25-Oct-2000 Abstract In the natural evolution of programming languages it is sometimes necessary to make changes that modify the behaviour of older programs. This PEP proposes a policy for implementing these changes in a manner respectful of the installed base of Python users. Implementation Details Implementation of this PEP requires the addition of a formal warning and deprecation facility that will be described in another proposal. Scope These guidelines apply to future versions of Python that introduce backward-incompatible behaviour. Backward incompatible behaviour is a major deviation in Python interpretation from an earlier behaviour described in the standard Python documentation. Removal of a feature also constitutes a change of behaviour. This PEP does not replace or preclude other compatibility strategies such as dynamic loading of backwards-compatible parsers. On the other hand, if execution of "old code" requires a special switch or pragma then that is indeed a change of behavior from the point of view of the user and that change should be implemented according to these guidelines. In general, common sense must prevail in the implementation of these guidelines. For instance changing "sys.copyright" does not constitute a backwards-incompatible change of behavior! Steps For Introducting Backwards-Incompatible Features 1. Propose backwards-incompatible behavior in a PEP. The PEP must include a section on backwards compatibility that describes in detail a plan to complete the remainder of these steps. 2. Once the PEP is accepted as a productive direction, implement an alternate way to accomplish the task previously provided by the feature that is being removed or changed. For instance if the addition operator were scheduled for removal, a new version of Python could implement an "add()" built-in function. 3. Formally deprecate the obsolete construct in the Python documentation. 4. Add an an optional warning mode to the parser that will inform users when the deprecated construct is used. In other words, all programs that will behave differently in the future must trigger warnings in this mode. Compile-time warnings are preferable to runtime warnings. The warning messages should steer people from the deprecated construct to the alternative construct. 5. There must be at least a one-year transition period between the release of the transitional version of Python and the release of the backwards incompatible version. Users will have at least a year to test their programs and migrate them from use of the deprecated construct to the alternative one. Local Variables: mode: indented-text indent-tabs-mode: nil End:

Paul, Your deprecation PEP looks good. A few comments: - I think that the one-year period may depend on the feature. Some may require an even longer time. Others less. - I think there will be cases where run-time checks are the only way to detect use of the old feature (e.g. I'm still struggling with how to change the division semantics). But this shouldn't stop it from becoming a PEP. Please arrange for a PEP number with Barry, the PEPmaster. --Guido van Rossum (home page: http://www.python.org/~guido/)
participants (2)
-
Guido van Rossum
-
Paul Prescod