[Python-Dev] When to remove deprecated stuff

Stephen J. Turnbull stephen at xemacs.org
Fri Aug 23 01:37:24 CEST 2013

R. David Murray writes:

 > It is the *change itself* that causes
 > action to be needed.  If a project has a policy of dealing with deprecated
 > features when the warnings happen, then they need to do that work before
 > the version where the feature is removed is released.  If they have
 > a policy of ignoring deprecation warnings, then they have to do that
 > work before their users can upgrade to the version where the feature
 > is removed.  So the pain exists in equal measure either way, with the
 > same periodicity, only the timing of when the work is done is affected
 > by whether or not you pay attention to deprecation warnings.

This is exactly correct analysis.  Changing the DeprecationWarning
policy is not going to save anybody any work, and it's not likely to
silence the grumbling.  It's the feature removal that causes the extra
work and that is what causes the complaints.

 > And yes, you presumably have a more relaxed fix schedule and
 > happier users if you pay attention to deprecation warnings, so you
 > should do that (IMO).

Sure, but human nature doesn't work that way.  Some people will,
others won't, and the latter are likely to think they have reason to

 > I'm asking if the bigger removals should be only on major version
 > boundaries, thus allowing *more* time for that relaxed fix mode for the
 > stuff that takes more work to fix.

My take is that it's not going to help that much.  You just don't know
what's going to take more work to fix.  A trivial-to-fix problem in a
proprietary library abandoned by its developer can take a complete
rewrite of your program.

More information about the Python-Dev mailing list