I like the idea of bumping the stacklevel in principle, but I am not sure it is all that practical. For example, if a warning came up when doing "x / y", I am assuming that it is emitted from within the ufunc np.divide(). So, you would need two stacklevels based on whether the entry point was the operator or a direct call to np.divide()? Also, I would imagine it might get weird for numpy functions called within other numpy functions. Or perhaps I am not totally understanding how this would be done?
Ben Root On Wed, Jan 27, 2016 at 5:07 PM, Ralf Gommers <ralf.gomm...@gmail.com> wrote: > > > On Wed, Jan 27, 2016 at 11:02 PM, sebastian <sebast...@sipsolutions.net> > wrote: > >> On 2016-01-27 21:01, Ralf Gommers wrote: >> >>> >>> 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? >>> >>> >> Yeah, I mean you could add tests for the individual functions in >> principle. >> I am not sure if adding an alias helps much, how are we going to test that >> warnings.warn is not being used? Seems like quite a bit of voodoo >> necessary >> for that. >> > > I was thinking something along these lines, but with a regexp checking for > warnings.warn: > https://github.com/scipy/scipy/blob/master/scipy/fftpack/tests/test_import.py > > Probably more trouble than it's worth though. > > Ralf > > > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion@scipy.org > https://mail.scipy.org/mailman/listinfo/numpy-discussion > >
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion
