[Python-Dev] PEP 466: Proposed policy change for handling network security enhancements

[Terry Reedy]

On 3/25/2014 6:15 PM, Nick Coghlan wrote:

> I am not sure how this meme got started, but let me be clear: the
> proposed policy DOES NOT provide blanket permission to break backwards
> compatibility in the affected modules. It only allows ADDING new
> features to bring these modules into line with their Python 3
> counterparts, making it easier for third party packages like requests to
> do the right thing in a cross-version compatible way.

I think the problem is that 'no new features' covers two quite different 
types of 'new' lumped together: change-new and new-new. New-new adds 
something completely new and does not break any sensible behavior that 
we worry about. We freely add new-new features with each new version. We 
do not add them to maintenance releases because then maintenance 
releases would be new versions. There are also considerations of 
incubation time, and the increased possibility of regressions with 
candidate-release versus alpha-beta-candidate-release schedules.

Change-new additions changing existing behavior (like changing a 
default) and can therefore break code that we care about. Even for new 
versions, we are wary them and may require deprecation. One of the 
ironies of change-new is that it is much more similar to change-fix, 
which is allowed as maintenance, than new-new is. The tracker 
controversies are about issues on the borderline between change-fix and 
change-new.

The original version of the PEP reference 434 as precedent. While partly 
valid, the reference could have fed the confusion because 434 does not 
draw the distinction given above. Indeed, part of the point of the PEP 
is that separating change-fix from change-new is difficult. As far as 
regressions go, a big new-new patch touching several untested modules 
worries me more than a small change-??? patch tweaking something in only 
one module, especially after writing tests for the module.

-- 
Terry Jan Reedy