[Python-Dev] When to remove deprecated stuff

[Petri Lehtinen]

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.

I hope the same will not start happening each time I upgrade Python.
When the removals happen on major version boundaries, it should be
more evident that something will break. Then people can enable
DepreationWarnings and test all the affected code thoroughly with the
new version before upgrading.

Petri