On Tue, May 22, 2012 at 2:45 PM, Nathaniel Smith <n...@pobox.com> wrote: > On Tue, May 22, 2012 at 11:06 AM, Robert Kern <robert.k...@gmail.com> wrote: >> On Tue, May 22, 2012 at 9:27 AM, Nathaniel Smith <n...@pobox.com> wrote: >>> So starting in Python 2.7 and 3.2, the Python developers have made >>> DeprecationWarnings invisible by default: >>> http://docs.python.org/whatsnew/2.7.html#the-future-for-python-2-x >>> http://mail.python.org/pipermail/stdlib-sig/2009-November/000789.html >>> http://bugs.python.org/issue7319 >>> The only way to see them is to explicitly request them by running >>> Python with -Wd. >>> >>> The logic seems to be that between the end-of-development for 2.7 and >>> the moratorium on 3.2 changes, there were a *lot* of added >>> deprecations that were annoying people, and deprecations in the Python >>> stdlib mean "this code is probably sub-optimal but it will still >>> continue to work indefinitely". >> >> That's not quite it, I think, since this change was also made in >> Python 3.2 and will remain for all future versions of Python. >> DeprecationWarning *is* used for things that will definitely be going >> away, not just things that are no longer recommended but will continue >> to live. Note that the 3.2 moratorium was for changes to the language >> proper. The point was to encourage stdlib development, including the >> removal of deprecated code. It was not a moratorium on removing >> deprecated things. The silencing discussion just came up first in a >> discussion on the moratorium. >> >> The main problem they were running into was that the people who saw >> these warnings the most were not people directly using the deprecated >> features; they were users of packages written by third parties that >> used the deprecated features. Those people can't do anything to fix >> the problem, and many of them think that something is broken when they >> see the warning (I don't know why people do this, but they do). This >> problem is exacerbated by the standard library's position as a >> standard library. It's at the base of everyone's stack so these >> indirect effects are quite frequent, quite possibly the majority case. >> Users would use a newer version of Python library than the third party >> developer tested on and see these errors instead of the developer. >> >> I think this concern is fairly general and applies to numpy nearly as >> much as it does the standard library. It is at the bottom of many >> people's stacks. Someone calling matplotlib.pyplot.plot() should not >> see a DeprecationWarning from numpy. > > Yes, good points -- though I think there is a also real cost/benefit > trade-off that depends on the details of how often these warnings are > issued, the specific user base, etc. > > Compared to stdlib, a *much* higher proportion of numpy-using code > consists of scripts whose only users are their authors, who didn't > think very carefully about error handling, and who will continue to > use these scripts for long periods of time (i.e. over multiple > releases). So I feel like we should have a higher threshold for making > warnings silent by default. > > OTOH, the distinction you suggest does make sense. I would summarize it as: > > - If a function or similar will just disappear in a future release, > causing obvious failures in any code that depends on it, then > DeprecationWarning is fine. People's code will unexpectedly break from > time to time, but in safe ways, and anyway downgrading is easy. > - Otherwise FutureWarning is preferred > > Does that sound like a reasonable rule of thumb?
Sure. -- Robert Kern _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion