[Numpy-discussion] Why does fancy indexing work like this?

Aaron Meurer asmeurer at gmail.com
Wed Jul 22 19:35:04 EDT 2020


> About your warnings, do you have a nice way to do that?  The mechanism
> for warnings does not really give a good way to catch that a warning
> was raised and then turn it into an error.  Unless someone contributes
> a slick way to do it, I am not sure the complexity pays off.

I don't really know how flags and options and such work in NumPy, but
I would imagine something like

if flags['post-deprecation'] = True: # Either a single flag for all
deprecations or a per-deprecation flag
    raise IndexError(...)
else:
    warnings.warn(...)

I don't know if the fact that the code that does this is in C
complicates things.

In other words, something that works kind of like __future__ flags for
upgrading the behavior to post-deprecation.

>
> IIRC, I added the note about raising the warning, because in this
> particular case the deprecation warning (turned into an error) happens
> to be chained due to implementation details.  (so you do see the
> "original" error printed out).

Yes, it's nice that you can see it. But for my use case, I want to be
able to "except IndexError". Basically, for ndindex, I test against
NumPy to make sure the semantics are identical, and that includes
making sure identical exceptions are raised. I also want to make it so
that the ndindex semantics always follow post-deprecation behavior for
any NumPy deprecations, since that leads to a cleaner API. But that
means that my test code has to do fancy shenanigans to catch these
deprecation warnings and treat them like the right errors.

But even as a general principle, I think for any deprecation warning,
users should be able to update their code in such a way that the
current version doesn't give the warning and also it will continue to
work and be idiomatic for future versions. For simple deprecations
where you remove a function x(), this is often as simple as telling
people to replace x() with y(). But these deprecations aren't so
simple, because the indexing itself is valid and will stay valid, it's
just the behavior that will change. If there's no way to do this, then
a deprecation warning serves little purpose because users who see the
warning won't be able to do anything about it until things actually
change. There would be little difference from just changing things
outright. For the list as tuple indexing thing, you can already kind
of do this by making sure your fancy indices are always arrays. For
the out of bounds one, it's a little harder. I guess for most
use-cases, you aren't actually checking for IndexErrors, and the thing
that will become an error usually indicates a bug in user code, so
maybe it isn't a huge deal (I admit my use-cases aren't typical).

Aaron Meurer


More information about the NumPy-Discussion mailing list