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

Robert Kern robert.kern at gmail.com
Tue May 22 09:49:46 EDT 2012

On Tue, May 22, 2012 at 2:45 PM, Nathaniel Smith <njs at pobox.com> wrote:
> 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?


Robert Kern

More information about the NumPy-Discussion mailing list