Just some notes from a performance perspective:

• until MAINT: Make the refactor suggested in prepare_index #8278, passing lists was probably slower anyway, because you ended up doing a bunch of heuristics and then calling PyTuple_new on the list on the C side.
• coercing a list to a tuple seems faster than building a tuple from scratch each time:

>>> a = np.zeros((2,)*10)

>>> sln = (slice(None),) # cache this to try and maximize speed
>>> %timeit a[sln*3 + (1,) + sln*6]
933 ns ± 20 ns per loop (mean ± std. dev. of 7 runs, 1000000 loops each)

>>> sl = list(sln * 10)
>>> %timeit sl[3] = 1; a[tuple(sl)]
858 ns ± 14.7 ns per loop (mean ± std. dev. of 7 runs, 1000000 loops each)

>>> %timeit sl[3] = 1; a[sl]  # passing a list is still fastest though
748 ns ± 27.3 ns per loop (mean ± std. dev. of 7 runs, 1000000 loops each)

Weirdly, writing it out explicitly is slowest of all:

In [42]: %timeit a[:,:,:,1,:,:,:,:,:,:]
985 ns ± 10.1 ns per loop (mean ± std. dev. of 7 runs, 1000000 loops each)

Dunno, might be unfair since python has to create the slice objects inside the timeit, etc.

The performance aspect probably doesn't matter so much; my comments were more about trying to make the code cleaner, with less conversions.

But I must admit that I've wondered why direct list comprehension is so much faster than doing it inside a function:

In [1]: %timeit [_i for _i in range(100)]
100000 loops, best of 3: 5.75 µs per loop

In [2]: %timeit list(_i for _i in range(100))
100000 loops, best of 3: 9.94 µs per loop

In [3]: %timeit tuple(_i for _i in range(100))
100000 loops, best of 3: 10.1 µs per loop

Sounds like this might need more discussion.

Pushing off to 1.15.

@mhvk: I'd prefer to leave the different tuple generation strategy to a different PR, and keep this change as small as possible.

Base switch above to recompute the diff. Shame there's no button to do that.

This maybe needs a doc change to https://docs.scipy.org/doc/numpy/reference/arrays.indexing.html#advanced-indexing

@eric-wieser Want to make that change or can I put this in.

Is there a plan for finishing this deprecation cycle? Would 1.17 be too soon to change this?

My gut feel is to leave this till (at least) 1.18 - this was quite an intrusive deprecation, and the PR references above suggest that downstream packages are still running into it every few months. Perhaps the deprecation NEP has a clear stance here.

Is there some reason you're hoping to get rid of this sooner? My main goal with this PR was to stop users writing code in this style, so I could stop trying to replicate it in my own __getitem__, without actually caring if the change ever happens

Right now, numpy_array[duck_array] can fail in some but not all circumstances to be interpreted as numpy_array[np.asarray(duck_array)]. This resulted in an issue for JAX: jax-ml/jax#620

But I agree, it seems that we should wait a bit longer before changing this.

Do the jax objects implement __array_ufunc__, or some other marker we could use look for meaning "do not use the deprecated behavior"?

They implement __array__ currently, and will soon implement both __array_ufunc__ and __array_function__ (jax-ml/jax#611).

I think the presence of __array__ is probably a good indication that we should not treat them as a tuple. Perhaps add a check for that attribute to shortcut this path, and if the type is not list?

Perhaps the deprecation NEP has a clear stance here.

It won't have an opinion on any specific cases. That was a clear message from review: just express the principles not current cases. I'm planning to get back to that NEP soon by the way.

I agree with waiting till 1.18

We might be able to finish the deprecation now for everything except lists, which I think have been all of the downstream cases that mattered.

We could also consider bumping this to an np.VisibleDeprecationWarning to try and flush out remaining downstream projects.

We could also consider bumping this to an np.VisibleDeprecationWarning to try and flush out remaining downstream projects.

I like that idea, if we can do that for 1.17 that will probably flush out many more issues for end users.