forked from python/peps
-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathpep-0291.txt
165 lines (128 loc) · 5.57 KB
/
pep-0291.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
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
PEP: 291
Title: Backward Compatibility for the Python 2 Standard Library
Version: $Revision$
Last-Modified: $Date$
Author: [email protected] (Neal Norwitz)
Status: Final
Type: Informational
Content-Type: text/x-rst
Created: 06-Jun-2002
Python-Version: 2.3
Post-History:
Abstract
========
This PEP describes the packages and modules in the Python 2
standard library which should remain backward compatible with
previous versions of Python. If a package is not listed here,
then it need only remain compatible with the version of Python it
is distributed with.
This PEP has no bearing on the Python 3 standard library.
Rationale
=========
Authors have various reasons why packages and modules should
continue to work with previous versions of Python. In order to
maintain backward compatibility for these modules while moving the
rest of the standard library forward, it is necessary to know
which modules can be modified and which should use old and
possibly deprecated features.
Generally, authors should attempt to keep changes backward
compatible with the previous released version of Python in order
to make bug fixes easier to backport.
In addition to a package or module being listed in this PEP,
authors must add a comment at the top of each file documenting
the compatibility requirement.
When a major version of Python is released, a Subversion branch is
created for continued maintenance and bug fix releases. A package
version on a branch may have a different compatibility requirement
than the same package on the trunk (i.e. current bleeding-edge
development). Where appropriate, these branch compatibilities are
listed below.
Features to Avoid
=================
The following list contains common features to avoid in order
to maintain backward compatibility with each version of Python.
This list is not complete! It is only meant as a general guide.
Note that the features below were implemented in the version
following the one listed. For example, features listed next to
1.5.2 were implemented in 2.0.
======= ======================================================
Version Features to Avoid
======= ======================================================
1.5.2 string methods, Unicode, list comprehensions,
augmented assignment (eg, +=), zip(), import x as y,
dict.setdefault(), print >> f,
calling f(\*args, \**kw), plus all features below
2.0 nested scopes, rich comparisons,
function attributes, plus all features below
2.1 use of object or new-style classes, iterators,
using generators, nested scopes, or //
without from __future__ import ... statement,
isinstance(X, TYP) where TYP is a tuple of types,
plus all features below
2.2 bool, True, False, basestring, enumerate(),
{}.pop(), PendingDeprecationWarning,
Universal Newlines, plus all features below
plus all features below
2.3 generator expressions, multi-line imports,
decorators, int/long unification, set/frozenset,
reversed(), sorted(), "".rsplit(),
plus all features below
2.4 with statement, conditional expressions,
combined try/except/finally, relative imports,
yield expressions or generator.throw/send/close(),
plus all features below
2.5 with statement without from __future__ import,
io module, str.format(), except as,
bytes, b'' literals, property.setter/deleter
======= ======================================================
Backward Compatible Packages, Modules, and Tools
================================================
============== ================== ============== =====
Package/Module Maintainer(s) Python Version Notes
============== ================== ============== =====
2to3 Benjamin Peterson 2.5
bsddb - Greg Smith 2.1
- Barry Warsaw
compiler Jeremy Hylton 2.1
decimal Raymond Hettinger 2.3 [2]
distutils Tarek Ziade 2.3
email Barry Warsaw 2.1 / 2.3 [1]
pkgutil Phillip Eby 2.3
platform Marc-Andre Lemburg 1.5.2
pybench Marc-Andre Lemburg 1.5.2 [3]
sre Fredrik Lundh 2.1
subprocess Peter Astrand 2.2
wsgiref Phillip J. Eby 2.1
xml (PyXML) Martin v. Loewis 2.0
xmlrpclib Fredrik Lundh 2.1
============== ================== ============== =====
==== ============= ==============
Tool Maintainer(s) Python Version
==== ============= ==============
None
==== ============= ==============
Notes
-----
1. The email package version 2 was distributed with Python up to
Python 2.3, and this must remain Python 2.1 compatible. email
package version 3 will be distributed with Python 2.4 and will
need to remain compatible only with Python 2.3.
2. Specification updates will be treated as bugfixes and backported.
Python 2.3 compatibility will be kept for at least Python 2.4.
The decision will be revisited for Python 2.5 and not changed
unless compelling advantages arise.
3. pybench lives under the Tools/ directory. Compatibility with
older Python versions is needed in order to be able to compare
performance between Python versions. New features may still
be used in new tests, which may then be configured to fail
gracefully on import by the tool in older Python versions.
Copyright
=========
This document has been placed in the public domain.
..
Local Variables:
mode: indented-text
indent-tabs-mode: nil
sentence-end-double-space: t
fill-column: 70
End: