`take` does not specify behavior for 0-D input array

[ndgrigorian]

It is not clarified in the spec how take should handle 0-D inputs for the indexed (x) argument.

NumPy allows this, even when axis=0

In [1]: import numpy as np

In [2]: np.take(np.ones(()), np.zeros(2, dtype="i4"), axis=0)
Out[2]: array([1., 1.])

of course, this won't work when using Python-sequence-style indexing

In [4]: np.ones(())[np.zeros(2, dtype="i4")]
---------------------------------------------------------------------------
IndexError                                Traceback (most recent call last)
Cell In[4], line 1
----> 1 np.ones(())[np.zeros(2, dtype="i4")]

IndexError: too many indices for array: array is 0-dimensional, but 1 were indexed

Referring to take(x, indices, axis=3 as "conceptually equivalent" to x[:, :, :, indices, ...] implicitly disallows this behavior.

The description of the output seems to agree

out (array) – an array having the same data type as x. The output array must have the same rank (i.e., number of dimensions) as x and must have the same shape as x, except for the axis specified by axis whose size must equal the number of elements in indices.

This wouldn't make much sense for a 0-D array, much like in cumulative_sum a similar conclusion was drawn.

[asmeurer]

I agree this is very similar to the discussion at #797. There numpy also allows it, but as @seberg pointed out, this is really legacy numpy behavior being too lax about this sort of thing. Note that here as with cumulative_sum, the issue is also that axis=0 doesn't make sense for a 0-D input, as it doesn't have any axes. With cumulative_sum, we decided to leave it undefined https://github.com/data-apis/array-api/pull/851/files. It really should be an error, but there's no reason for the standard to take a hard line here especially given some libraries do allow it. That same conclusion makes sense to me here too.