[Python-Dev] When to remove deprecated stuff

[Terry Reedy]

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.

-- 
Terry Jan Reedy