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

Hameer Abbasi einstein.edison at gmail.com
Tue Jun 26 04:48:22 EDT 2018

 I would disagree here. For libraries like Dask, XArray, pydata/sparse,
XND, etc., it would be bad for them if there was continued use of “weird”
indexing behaviour (no warnings means more code written that’s… well… not
exactly the best design). Of course, we could just choose to not support
it. But that means a lot of code won’t support us, or support us later than
we desire.

I agree with your design of “let’s limit the number of
warnings/deprecations to cases that make very little sense” but there
should be warnings.

Specifically, I recommend warnings for mixed slices and fancy indexes, and
warnings followed by errors for cases where the transposing behaviour

Best Regards,
Hameer Abbasi
Sent from Astro <https://www.helloastro.com> for Mac

On 26. Jun 2018 at 10:33, Robert Kern <robert.kern at gmail.com> wrote:

On Tue, Jun 26, 2018 at 1:26 AM Travis Oliphant <teoliphant at gmail.com>

> I like the proposal generally.  NumPy could use a good orthogonal indexing
> method and a vectorized-indexing method is fine too.
> Robert Kern is spot on with his concerns as well.  Please do not change
> what arr[idx] does except to provide warnings and perhaps point people to
> new .oix and .vix methods.  What indexing does is documented (if hard to
> understand and surprising in a particular sub-case).
> There is one specific place in the code where I would make a change to
> raise an error rather than change the order of the axes of the output to
> provide a consistent subspace.  Even then, it should be done as a
> deprecation warning and then raise the error.
> Otherwise, just add the new methods and don't make any other changes until
> a major release.

I'd suggest that the NEP explicitly disclaim deprecating current behavior.
Let the NEP just be about putting the new features out there. Once we have
some experience with them for a year or three, then let's talk about
deprecating parts of the current behavior and make a new NEP then if we
want to go that route. We're only contemplating *long* deprecation cycles
anyways; we're not in a race. The success of these new features doesn't
really rely on the deprecation of current indexing, so let's separate those

Robert Kern

NumPy-Discussion mailing list
NumPy-Discussion at python.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20180626/e410d9d2/attachment.html>

More information about the NumPy-Discussion mailing list