iSharkFly-Open
/
python-peps
mirror of https://github.com/python/peps.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Restify PEP-5

This commit is contained in:
Matthias Bussonnier 2016-06-19 12:36:36 -07:00
parent cce5754f28
commit 56b9952222
1 changed files with 53 additions and 50 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

103
pep-0005.txt
View File

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