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. _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
