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

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 complain.

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