[Numpy-discussion] NEP 31 — Context-local and global overrides of the NumPy API
einstein.edison at gmail.com
Tue Sep 10 06:48:24 EDT 2019
On 09.09.19 03:26, Nathaniel Smith wrote:
> Generic in the sense that you can write __array_ufunc__ once and have
> it work for all ufuncs.
You can do that too with __ua_function__, you get np.ufunc.__call__,
with self=<any-ufunc>. The same holds for say, RandomState objects, once
>>> Most duck array libraries can write a single
>>> implementation of __array_ufunc__ that works for *all* ufuncs, even
>>> new third-party ufuncs that the duck array library has never heard of,
>> I see where you're going with this. You are thinking of reusing the ufunc implementation to do a computation. That's a minor use case (imho), and I can't remember seeing it used.
> I mean, I just looked at dask and xarray, and they're both doing
> exactly what I said, right now in shipping code. What use cases are
> you targeting here if you consider dask and xarray out-of-scope? :-)
>> this is case where knowing if something is a ufunc helps use a property of it. so there the more specialized nature of __array_ufunc__ helps. Seems niche though, and could probably also be done by checking if a function is an instance of np.ufunc via __array_function__
> Sparse arrays aren't very niche... and the isinstance trick is
> possible in some cases, but (a) it's relying on an undocumented
> implementation detail of __array_function__; according to
> __array_function__'s API contract, you could just as easily get passed
> the ufunc's __call__ method instead of the object itself, and (b) it
> doesn't work at all for ufunc methods like reduce, outer, accumulate.
> These are both show-stoppers IMO.
It does work for all ufunc methods. You just get passed in the
appropriate method (ufunc.reduce, ufunc.accumulate, ...), with
More information about the NumPy-Discussion