[Numpy-discussion] Bump warning stacklevel

Sebastian Berg sebastian at sipsolutions.net
Thu Jan 28 03:18:25 EST 2016


On Mi, 2016-01-27 at 17:12 -0500, Benjamin Root wrote:
> 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?

You are right of course, and the answer is that I was never planning on
fixing that. This is only for warnings by functions directly called by
the users (or those which always go through one more level, though I
did not check the C-api for such funcs). Also C-Api warnings are
already correct in this regard automatically.

Anyway, I still think it is worth it, even if in practice a lot of
warnings are such things as ufunc warnings from inside a python func.
And there is no real way to change that, that I am aware of, unless
maybe we add a warning_stacklevel argument to those C-api funcs ;).

- Sebastian


> Ben Root
> 
> 
> On Wed, Jan 27, 2016 at 5:07 PM, Ralf Gommers <ralf.gommers at gmail.com
> > wrote:
> > 
> > 
> > On Wed, Jan 27, 2016 at 11:02 PM, sebastian <
> > sebastian at 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/mas
> > ter/scipy/fftpack/tests/test_import.py
> > 
> > Probably more trouble than it's worth though.
> > 
> > Ralf
> >  
> > 
> > _______________________________________________
> > NumPy-Discussion mailing list
> > NumPy-Discussion at scipy.org
> > https://mail.scipy.org/mailman/listinfo/numpy-discussion
> > 
> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion at scipy.org
> https://mail.scipy.org/mailman/listinfo/numpy-discussion
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20160128/ab760ff2/attachment.sig>


More information about the NumPy-Discussion mailing list