[Numpy-discussion] NEP 21: Simplified and explicit advanced indexing (original) (raw)

Sebastian Berg sebastian at sipsolutions.net
Tue Jun 26 04:35:20 EDT 2018

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:

> > 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.

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>

More information about the NumPy-Discussion mailing list