[Python-Dev] When to remove deprecated stuff (original) (raw)
Terry Reedy tjreedy at udel.edu
Thu Aug 15 19:34:12 CEST 2013
- Previous message: [Python-Dev] When to remove deprecated stuff (was: Deprecating the formatter module)
- Next message: [Python-Dev] When to remove deprecated stuff
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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
- Previous message: [Python-Dev] When to remove deprecated stuff (was: Deprecating the formatter module)
- Next message: [Python-Dev] When to remove deprecated stuff
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]