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 warning):
np.mean([])
would not print:
/usr/lib/python2.7/dist-packages/numpy/core/_methods.py:55: 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? Ralf