On Wed, Jan 27, 2016 at 7:26 PM, Sebastian Berg <sebastian@sipsolutions.net> wrote:
Hi all,

in my PR about warnings suppression, I currently also have a commit
which bumps the warning stacklevel to two (or three), i.e. use:

warnings.warn(..., stacklevel=2)

(almost) everywhere. This means that for example (take only the empty


would not print:

RuntimeWarning: Mean of empty slice.
  warnings.warn("Mean of empty slice.", RuntimeWarning)

but instead print the actual `np.mean([])` code line (the repetition of
the warning command is always a bit funny).

The advantage is nicer printing for the user.

The disadvantage would probably mostly be that existing warning filters
that use the `module` keyword argument, will fail.

Any objections/thoughts about doing this change to try to better report
the offending code line?

This has annoyed me for a long time, it's hard now to figure out where warnings really come from. Especially when running something large like scipy.test(). So +1.
Frankly, I am not sure whether there might be
a python standard about this, but I would expect that for a library
such as numpy, it makes sense to change. But, if downstream uses
warning filters with modules, we might want to reconsider for example.

There probably are usages of `module`, but I'd expect that it's used a lot less than `category` or `message`. A quick search through the scipy repo gave me only a single case where `module` was used, and that's in deprecated weave code so soon the count is zero.  Also, even for relevant usage, nothing will break in a bad way - some more noise or a spurious test failure in numpy-using code isn't the end of the world I'd say.

One issue will be how to keep this consistent. `stacklevel` is used so rarely that new PRs will always omit it for new warnings. Will we just rely on code review, or would a private wrapper around `warn` to use inside numpy plus a test that checks that the wrapper is used everywhere be helpful here?