[Numpy-discussion] Adding to the non-dispatched implementation of NumPy methods
Marten van Kerkwijk
m.h.vankerkwijk at gmail.com
Sat Apr 27 09:51:25 EDT 2019
I agree with Ralf that there are two discussions going on, but also with
Hameer that they are related, in that part of the very purpose of
__array_function__ was to gain freedom to experiment with implementations.
And in particular the freedom to *assume* that inputs are arrays so that we
can stop worrying about breaking subclasses and duck arrays: with
__array_function__, we can now (well, eventually) tell people to just
override the function and make it do what they want. In that respect, if
having `__numpy_implementation__` means it would not change the existing
situation with backwards compatibility, then that is bad: we do want to
change that! The point is to keep the exposed API stable, not the
Of course, the idea proposed here is not to keep the implementation stable,
but rather to help people implement __array_function__ who are daunted by
the many functions that can be overridden, especially for those classes for
which many numpy functions work out of the box: they can have a default of
just calling the old implementation.
In the end, the proposed goal for __numpy_implementation__ really seems
simple: to provide a better name for __wrapped__. But to me the discussion
has proven that this is in fact not a good idea. It does suggest stability
where there should be none, and the name itself is contentious. Maybe it is
best to just stick with __wrapped__? If so, the the only change would be
that we mention it in the NEP, making again explicit that the wrapped
implementation can and will be changed.
All the best,
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the NumPy-Discussion