I can confirm that downloading the object.inv from the build and inspecting it gives the correct output now:

$ sphobjinv suggest ~/Downloads/objects.inv np.where
...

Project: NumPy
Version: 1.25.dev0

8110 objects in inventory.

--------------------------------------------------------------------

2 results found at/above current threshold of 75.

:py:function:`numpy.where`
:std:doc:`reference/generated/numpy.where`

Thanks @seberg this is a very clean fix

Hi, it seems like this PR changed the type of NumPy functions from function to np._ArrayFunctionDispatcher.

We have seen this changed of behavior via scikit-learn/scikit-learn#25202 (see this log)

For now, we have this temporary fix: scikit-learn/scikit-learn#25498

PS: I do not know how the tone of this message was like, but I was probably annoyed by other reasons when writing it. Sorry for the annoyance.

I would might suggest to spell it as type(np.median) or so, since otherwise we should move this somewhere else (the problem there is if someone has the idea to make median a ufunc :), which is rather theoretical, but maybe there is another less ufunc-like function).

Yes, the previous PR changed it for much faster dispatching with keyword arguments especially. Does this break anything important to users (i.e. in released versions?) or just a small thing?

At least from my perspective there would have to be a decent amount of fallout to change it back, since it just mean unnecessary overhead. Note that the current logic also seems to be missing the built-in (C defined) methods in theory. (NumPy effectively doesn't have those, because since 1.17 all functions were wrapped into Python functions unless opted out).

Yes, the previous PR changed it for much faster dispatching with keyword arguments especially. Does this break anything important to users (i.e. in released versions?) or just a small thing?

For now, nothing breaks in our release version, it's more that I wanted to raise awareness about this change of behavior which impact downstream maintainers, such as scikit-learn's.

I do not suggest nor demand making changes (I have not spent time understanding NumPy internals in this regards), but would like to know if you want to address it in NumPy so that type inspection for (some) NumPy objects remains unchanged. 🙂

I do not think there is a way to guarantee that you get a Python function back other than wrapping everything or reverting. Meaning you would buy it at a cost of probably something like 50-100ns per call.
The current logic also for example doesn't allow ufuncs. So no, unless we have to go into firefighting 🔥🚨🚒 mode, I don't see a reason to change anything.

OK, then my interjection is irrelevant and can be ignored.