DEPR: is_array_like

[jbrockmendel]

is_array_like is a a one-liner return is_list_like(obj) and hasattr(obj, "dtype"). It does not recognize pyarrow objects. Often we use it when we really want something like isinstance(obj, (np.ndarray, Series, Index, ExtensionArray)), which is much more typing-friendly. We should replace its usage with these more specific checks and deprecate it.

Discussed briefly in a dev meeting a couple months ago with generally positive reception.

[rhshadrach]

which is much more typing-friendly

Would using a TypeGuard with updated logic be better? If we ever want to change what is being identified as array-like, inlining would require trying to grep through the codebase.

[jbrockmendel]

I'd be fine with that

[phofl]

sounds good to me as well

[lithomas1]

Going to tag this as good first issue.

See https://pandas.pydata.org/docs/development/contributing_codebase.html#backwards-compatibility for how to do a deprecation.

[phofl]

I might be missing something but I think we agreed on changing the implementation, not deprecating the function?

[rhshadrach]

I think we agreed on changing the implementation, not deprecating the function?

We could still deprecate the function and make it internal. This would disadvantage users utilizing it but would make any future changes not have to go through deprecation. Not sure how much this might be used today.

[phofl]

I fixed a bunch of things in Dask when we merged the other deprecations. This has value for downstream libraries, I am -1 on deprecating as soon as the functions become more than a simple isinstance check

[jbrockmendel]

I guess I imagine implementing a new non-public version and changing out internal usages to it. Then can either deprecate the old one saying it's moving to the new one's behavior or deprecate it entirely or just let it sit there unused forever.

[phofl]

Just switching the implementation is probably not straightforward?

[jbrockmendel]

Probably not, no. I expect there are a bunch of subtle bugs where we used is_arraylike but really meant something more akin to isinstance(obj, (np.ndarray, ExtensionArray, Series, Index))

[jbrockmendel]

Another thought that doesn't fit perfectly here but close enough: we have places where we check for hasattr(obj, "dtype") that would be nice to subsume into one pattern, and also we have checks for __array__ both in Index.__new__ and in sanitize_array (unfortunately with slightly different behavior) that would be good to standardize.

[jbrockmendel]

I count 26 non-test uses of is_array_like internally. One of them is removed by #52973. One more in core.algorithms I have an upcoming PR to deprecate, and one other in _ensure_arraylike I'd like to deprecate but that will take more effort. Both in core.common are pretty clearly wrong (upcoming PR will fix). 5 in reshape.merge are on the chopping block xref #48454. One in sparse.array seems unnecessary. Still looking through the rest.

Point being: it seems like getting rid of internal usages may be feasible and worthwhile.

[Aloqeely]

Any final thought on this? I can start working on it if all agree on just changing the implementation without any deprecating