This repository has been archived by the owner on Nov 5, 2021. It is now read-only.
forked from python/peps
/
pep-0005.txt
83 lines (64 loc) · 2.97 KB
/
pep-0005.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
PEP: 5
Title: Guidelines for Language Evolution
Version: $Revision$
Last-Modified: $Date$
Author: paul@prescod.net (Paul Prescod)
Status: Active
Type: Process
Content-Type: text/x-rst
Created: 26-Oct-2000
Post-History:
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 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: