79 lines
3.0 KiB
Plaintext
79 lines
3.0 KiB
Plaintext
|
PEP: 5
|
|||
|
|
Title: Guidelines for Language Evolution
|
|||
|
|
Version: $Revision$
|
|||
|
|
Author: paul@prescod.net (Paul Prescod)
|
|||
|
|
Status: Active
|
|||
|
|
Type: Informational
|
|||
|
|
Created: 26-Oct-2000
|
|||
|
|
|
|||
|
|
Abstract
|
|||
|
|
|
|||
|
|
In the natural evolution of programming languages it is sometimes
|
|||
|
|
necessary to make changes that modify the behavior 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 behavior. Backward incompatible behavior is
|
|||
|
|
a major deviation in Python interpretation from an earlier
|
|||
|
|
behavior described in the standard Python documentation. Removal
|
|||
|
|
of a feature also constitutes a change of behavior.
|
|||
|
|
|
|||
|
|
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 Introducing 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:
|