[Python-Dev] When to remove deprecated stuff

[Antoine Pitrou]

Le Thu, 22 Aug 2013 14:00:06 +0300,
Petri Lehtinen <petri at digip.org> a écrit :
> Terry Reedy wrote:
> > On 8/15/2013 8:29 AM, R. David Murray wrote:
> > 
> > >A number of us (I don't know how many) have clearly been thinking
> > >about "Python 4" as the time when we remove cruft.  This will not
> > >cause any backward compatibility issues for anyone who has paid
> > >heed to the deprecation warnings, but will for those who haven't.
> > >The question then becomes, is it better to "bundle" these removals
> > >into the Python 4 release, or do them incrementally?
> > 
> > 4.0 will be at most 6 releases after the upcoming 3.4, which is 9 to
> > 12 years, which is 7 to 10 years after any regular 2.7 maintainance
> > ends.
> > 
> > The deprecated unittest synonyms are documented as being removed in
> > 4.0 and that already defines 4.0 as a future cruft-removal release.
> > However, I would not want it defined as the only cruft-removal
> > release and used as a reason or excuse to suspend removals until
> > then. I would personally prefer to do little* removals
> > incrementally, as was done before the decision to put off 2.x
> > removals to 3.0. So I would have 4.0 be an 'extra' or 'bigger' cruft
> > removal release, but not the only one.
> > 
> > * Removing one or two pure synonyms or little used features from a
> > module. The unittest synonym removal is not 'little' because there
> > are 13 synonyms and at least some were well used.
> > 
> > >If we are going to do them incrementally we should make that
> > >decision soonish, so that we don't end up having a whole bunch
> > >happen at once and defeat the (theoretical) purpose of doing them
> > >incrementally.
> > >
> > >(I say theoretical because what is the purpose?  To spread out the
> > >breakage pain over multiple releases, so that every release breaks
> > >something?)
> > 
> > Little removals will usually break something, but not most things.
> > Yes, I think it better to upset a few people with each release than
> > lots of people all at once. I think enabling deprecation notices in
> > unittest is a great idea. Among other reasons, it should spread the
> > effect of bigger removals scheduled farther in the future over the
> > extended deprecation period.
> > 
> > Most deprecation notices should provide an alternative. (There might
> > be an exception is for things that should not be done ;-). For
> > module removals, the alternative should be a legacy package on PyPI.
> 
> Removing some cruft on each release can be very painful for users.
> 
> Django's deprecation policy works like this: They deprecate something
> in version A.B. It still works normally in A.B+1, generates a
> (silenced) DeprecationWarning in A.B+2, and is finally removed in
> A.B+3. So if I haven't read through the full release notes of each
> release nor enabled DeprecationWarnings, I end up having something
> broken each time I upgrade Django.

So, again, perhaps we can stop silencing DeprecationWarning.

Regards

Antoine.