[Python-Dev] When to remove deprecated stuff (original) (raw)

Michael Foord fuzzyman at voidspace.org.uk
Thu Aug 22 15:45:29 CEST 2013

On 22 Aug 2013, at 14:00, Petri Lehtinen <petri at digip.org> wrote:

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 you're still using features deprecated three releases ago, you haven't checked for DeprecationWarnings and it's Django making your life difficult?

Why not check for the deprecation warnings?

Michael

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

Python-Dev mailing list Python-Dev at python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk

-- http://www.voidspace.org.uk/

May you do good and not evil May you find forgiveness for yourself and forgive others May you share freely, never taking more than you give. -- the sqlite blessing http://www.sqlite.org/different.html

More information about the Python-Dev mailing list