[Python-Dev] Policy Decisions, Judgment Calls, and Backwards Compatibility (was Re: splitext('.cshrc'))

[Terry Reedy]

<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,
better API
* 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. 
Unfortunately,

* 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 
cost.)

* 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 
influence judgment.

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 
bug-fix releases).

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 
package.

Terry Jan Reedy