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


_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Reply via email to