[Python-Dev] When to remove deprecated stuff

[Michael Foord]

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