[Python-Dev] When to remove deprecated stuff
tjreedy at udel.edu
Thu Aug 15 19:34:12 CEST 2013
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
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
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
More information about the Python-Dev