We have always said we take "array like" input, however when we started saying that there was numarray/numeric, then numpy, and always Python lists. Later we started to have some special cases to supportpandas.Series (both on straight conversion and to pick of the index). However, the the current rise of sturcutred and array-like libraries (xarray, akwaardarray, pandas recent changes, the fleet of GPU libraries, dask, the pandas-likes, ...) things have become a bit fuzzier and different parts of the library are not completely consistent with what they support.

There has been work recently (most recently#22560) to consolidate all of the attempted coercion into one place in the code and articulate exactly what we mean by "array like".

We have standardized on the chain of:

• isinstance(obj, np.array)
• obj.to_numpy
• obj.values
• np.asanyarray(obj)

We should: document this chain as what it means to "be array like" including including the expected shapes / squashing of these things (e.g. when do we expect (n,) vs (1, n) vs (n, 1) shaped arrays).

If we do this we may want to make_unpack_to_numpy and maybe our 1D and 2D coercion function public so that the datastructure libraries can test if they comply. We should, however, make clear in the documentation that the API garuntees on these functions will be a bit weaker in that we will reserve the right to make the more permissive in the future (that is input that we currently bounce may be handled in the future with no warning), but anything that we correctly get to numpy will continue to work (or go through the normal deprecation cycle).

If we do this we should also provide a set of numpy arrays and/or lists and the expected return through the conversion as a fixture.