[Python-Dev] Policy Decisions, Judgment Calls, and Backwards Compatibility (was Re: splitext('.cshrc'))
tjreedy at udel.edu
Fri Mar 9 06:42:46 CET 2007
<glyph at divmod.com> wrote in message
news:20070309003135.7769.1063793143.divmod.xquotient.177 at joule.divmod.com...
martin at v.loewis.de wrote:
My understanding of the current backwards-compatibility policy for
Python, the one that Twisted has been trying to emulate strictly, is
that, for each potentially incompatible change, there will be:
* at least one release with a pending deprecation warning and new,
* at least one release with a deprecation warning
* some number of releases later, the deprecated functionality is removed
There is not and hardly can be any such policy for bug fixes.
* Honest people can disagree about whether a change is a bug fix or feature
addition or replacement. And there will be borderline cases regardless of
one's definition, unless one makes either category empty. (Having only one
category and hence only one change policy would simplify life but at some
* Fixing bugs can break code just as it fixes other code.
I believe the current policy is that depending on buggy behavior, as
opposed to working around it, is proceed at your own risk. Bugs can be
fixed without notice, at the next bug fix release. On the other hand, bug
fixes can and sometime are delayed or modified in recognition of degrees of
bugginess and differences of opinions and cost-benefit analyses. But
deviations from a rigid procedure require case-by-case judgments, to me
preferably based on information-gathering and discussion and a chance to
For new features that don't break code (that doesn't depend on the features
absence), the current (and somewhat new) policy is to wait until the next
minor .x feature release, skipping any micro .x.y releases (now called
For replacement features, the policy is what you give above.
Example: f(*args) instead of apply(f, args).
At one time, the expectation was that removal could be and possibly would
be one release after deprecation. It is currently to wait until 3.0. What
it will be after that I have not seen discussed.
Semantic changes are trickier. We don't want a different API when we want
a different meaning for the currently API.
The integer division change is a mixture. Int//int replaces int/int and is
already available. But int/int will change meaning to
float(int)/float(int) rather than being removed.
So I see five categories of code change -- clear bug, possibly fuzzy bug,
semantic change, replacement, and addition -- each with different
appropriate policies. And there are mixtures that belong together in a
Terry Jan Reedy
More information about the Python-Dev