[Numpy-discussion] NEP 21: Simplified and explicit advanced indexing

[Sebastian Berg]

On Tue, 2018-06-26 at 01:21 -0700, Robert Kern wrote:
> On Tue, Jun 26, 2018 at 12:58 AM Sebastian Berg
> <sebastian at sipsolutions.net> wrote:

<snip>

> > 
> > Yes, that is true, but I doubt you will find a lot of code path
> > that
> > need the current indexing as opposed to vindex here,
> 
> That's probably true! But I think it's besides the point. I'd wager
> that most code paths that will use .vindex would work perfectly well
> with current indexing, too. Most of the time, people aren't getting
> into the hairy corners of advanced indexing.
> 

Right, the proposal was to have DeprecationWarnings when they differ,
now I also thought DeprecationWarnings on two advanced indexes in
general is good, because it is good for new users.
I have to agree with your argument that most of the confused should be
running into broadcast errors (if they expect oindex vs. fancy). So I
see this as a point that we likely should just limit ourselves at least
for now to the cases for example with sudden transposing going on.

However, I would like to point out that the reason for the more broad
warnings is that it could allow warping normal indexing at some point.
Also it decreases traps with array-likes that behave differently.


> Adding to the toolbox is great, but I don't see a good reason to take
> out the ones that are commonly used quite safely.
>  
> > and the idea was
> > to have a method to get the old behaviour indefinitely. You will
> > need
> > to add the `.vindex`, but that should be the only code change
> > needed,
> > and it would be easy to find where with errors/warnings.
> 
> It's not necessarily hard; it's just churn for no benefit to the
> downstream code. They didn't get a new feature; they just have to run
> faster to stay in the same place.
> 

So, yes, it is annoying for quite a few projects that correctly use
fancy indexing, but if we choose to not annoy you a little, we will
have much less long term options which also includes such projects
compatibility to new/current array-likes.
So basically one point is: if we annoy scikit-image now, their code
will work better for dask arrays in the future hopefully.

- Sebastian


> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion at python.org
> https://mail.python.org/mailman/listinfo/numpy-discussion
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20180626/a85f2c8d/attachment.sig>