DEPR: allowing unknowns in take
- [ ] closes #xxxx (Replace xxxx with the GitHub issue number)
- [x] [Tests added and passed](https://pandas.pydata.org/pandas-docs/dev/development/contributing_codebase.html#writing-tests) if fixing a bug or adding a new feature
- [ ] All [code checks passed](https://pandas.pydata.org/pandas-docs/dev/development/contributing_codebase.html#pre-commit).
- [ ] Added [type annotations](https://pandas.pydata.org/pandas-docs/dev/development/contributing_codebase.html#type-hints) to new arguments/methods/functions.
- [x] Added an entry in the latest `doc/source/whatsnew/vX.X.X.rst` file if fixing a bug or adding a new feature.

What's the motivation for this change? is_array_like is an antipattern #52834 Seems pretty heavy to deprecate this usage just to avoid `is_array_like`, especially since numpy.take will accept array-likes. Why can't we just replace `not is_array_like` with `not isinstance(..., (np.ndarray, ...))` and accept we may be calling `asarray` on more items? > Why can't we just replace not is_array_like with not isinstance(..., (np.ndarray, ...)) and accept we may be calling asarray on more items?

That's a reasonable intuition, but np.asarray can have weird behaviors which we generally work around (but unfortunately have several slightly-different implementations of).  My thought is to avoid that by just having the user do that casting. But we'll still allow e.g. a list in DataFrame.take and others? This seems inconsistent. > But we'll still allow e.g. a list in DataFrame.take and others? This seems inconsistent.

This is for the first arg in take, not the indices. I personally wouldn't expect pandas to implement taking from a general sequence (e.g. a list); I'm okay with deprecating from that perspective. @mroeschke gentle ping on this and #52986 Thanks @jbrockmendel 