OK, sorry about that - its pretty hard to track all the ways we can coerce to numpy, and we are working hard to consolidate them. Can astropy make a mocked up class for us that we can use for testing that should work? Currently looks like we are supporting to_numpy and then calling np.atleast_1d for some cases, but not doing it always.

Its pretty easy to add a check for __array__ to the fallbacks. I think it just becomes an issue of what takes precedence if an object has multiple array accessors. My knee jerk would be:

to_numpy > values > __array__, but I'm not sure if there is a proper convention here.

I think __array__ should be first.

I am going to ping @keflavich and @mhvk here in case they have insights on astropy interface.

I think __array__ should be first.

The private before the public?

I would say actual protocol rather than ad-hoc protocol.

@jklymak - __array__ is the standard protocol for allowing anything to be coerced to a numpy array - it is was np.array looks for too (which is why np.atleast_1d worked - it uses np.asanyarray which is short for np.array(<input>, subok=True, copy=False). It may be worth checking whether the pandas object doesn't support it already - I wouldn't be surprised...

Thanks, that makes sense, though pandas definitely was failing, so we had to add the unpacking here (I don't know if you saw the diff for #22141 for what we were doing before that PR?)

We are completely untested on custom __array__ objects, so it would be very helpful if someone knowledgeable could mock one up for us just so we don't break this ability in the future.

We are always delicate about what point we coerce to numpy because sometimes objects we get passed have units, and we don't want to strip those out too early. Hence the desire to consolidate all this, and not rely on np.(as)(any)array in a blanket sense. But any advice on how to do this properly is gratefully received.

For instance, the fix in #22975 fails the unit interface tests....

@jklymak - very much appreciated that you try to remove too much explicit casting to numpy arrays! It seems reasonable to leave it to objects that are passed in to try to be good enough duck types.

Can astropy make a mocked up class for us that we can use for testing that should work?

Here is a minimal reproducer class based on astropy.convolution.core.Kernel:

import numpy as np
import matplotlib.pyplot as plt 

class Kernel:
    def __init__(self, array):
        self._array = np.asanyarray(array)

    def __array__(self):
        return self._array
    
    @property
    def shape(self):
        return self._array.shape

kernel = Kernel([1, 2, 3, 4, 5])
plt.plot(kernel)

@WilliamJamieson Thanks a lot. We can base a test around this, and make sure we don't break you (and others presumably) in the future. And again, sorry for the hassle.

Just linking with #22645