[Numpy-discussion] un-silencing Numpy's deprecation warnings

Nathaniel Smith njs at pobox.com
Tue May 22 09:45:59 EDT 2012

On Tue, May 22, 2012 at 11:06 AM, Robert Kern <robert.kern at gmail.com> wrote:
> On Tue, May 22, 2012 at 9:27 AM, Nathaniel Smith <njs at 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?

-- Nathaniel

More information about the NumPy-Discussion mailing list