Just to be sure it wasn't some weird Python 3.9 thing, here's a 3.11 environment:

conda create -n numpy_dev_py311 python=3.11 numpy
conda activate numpy_dev_py311
conda uninstall -y --force numpy
python -m pip install --index-url https://pypi.anaconda.org/scipy-wheels-nightly/simple/ --trusted-host pypi.anaconda.org --no-deps --pre --upgrade numpy
python -c "import numpy as np; import types; print(isinstance(np.size, types.FunctionType))"

Prints False, but should be True unless this is expected.

This is happening because of #23020, which moved the __array_function__ dispatcher into C. Maybe @seberg has other thoughts given the downstream breakage in holoviews, but one way holoviews could fix this is by using the inspect module:

In [7]: inspect.isroutine(np.size)
Out[7]: True

#23032 is related as well, since the same change also impacted sphinx.

I'm not sure inspect would work for them. At least not as a drop in replacement. They are checking if some object is an instance of one or more classes. In this particular case they are checking that something callable is a FunctionType which is maybe too strict of a check (a class with a __call__ method returns False for this isinstance check).

Maybe it will require more work in holoviews.

Edit: Actually a __call__ method on an instance fails isroutine too.

isroutine is more limited than having a __call__ or callable. typing.Callable also works for isinstance().
Not sure if there is a different abstract class that would be a simple drop-in replacement, although it would be pretty trivial to write something fairly sensible:

import abc

class MyCallable(abc.ABC):
    @classmethod
    def __subclasscheck__(cls, other):
        return hasattr(other, "__call__")

Note that FunctionType (unlike isroutine) does not even cover functions defined in C. Is this a serious "everything is coming down crashes" thing, or more a question of how to fix it in holoviz?

Is this a serious "everything is coming down crashes" thing, or more a question of how to fix it in holoviz?

I honestly have no idea. Holoviews is used in one small part of one small utility function of the library I work on. Otherwise, I guess technically this could trigger edge cases in any library that likes to pass function pointers around.

I did notice something interesting, if you print out the repr it still says/thinks it is a function:

>>> import numpy as np
>>> np.size
<function size at 0x7f711b14cc30>
>>> np.size.__class__
<class 'numpy._ArrayFunctionDispatcher'>
>>> np.size.__class__.__class__
<class 'type'>

But I guess _ArrayFunctionDispatcher being of type type means np.size is an instance of a class. Unless _ArrayFunctionDispatcher was made to be a subclass (or call into) the builtin Function type we can't hope for np.size to be a more recognizable function. And like you said, if any part of this is C functions that aren't carefully handled isinstance with FunctionType isn't going to work anyway.

Ok enough rambling...I'm sure there will be other cases of this change causing issues downstream but the fact that no one has brought it up before me suggests you/we won't find out until release.

The issues in holoviews have now been fixed by using Callable instead of FunctionType. Feel free to close this or completely rewrite _ArrayFunctionDispatcher to present as functions 😉

Feel free to close this or completely rewrite _ArrayFunctionDispatcher to present as functions

That is not possible, nor is it something Python does. Check abs, or len or functools.partial or any function defined in Cython or...

Wow, this led me down a short rabbit hole. Python (def/lambda) functions versus all other types of callables. Interesting. Thanks.