diff options
Diffstat (limited to 'doc/neps/nep-0018-array-function-protocol.rst')
| -rw-r--r-- | doc/neps/nep-0018-array-function-protocol.rst | 29 |
1 files changed, 16 insertions, 13 deletions
diff --git a/doc/neps/nep-0018-array-function-protocol.rst b/doc/neps/nep-0018-array-function-protocol.rst index da4c5de32..d4ba7879b 100644 --- a/doc/neps/nep-0018-array-function-protocol.rst +++ b/doc/neps/nep-0018-array-function-protocol.rst @@ -795,27 +795,30 @@ If we want to include them in the future, the easiest way to do so would be to update the ``array_function_dispatch`` decorator to add them as function attributes. -Protocols for methods -~~~~~~~~~~~~~~~~~~~~~ - -NumPy defines a number of classes with methods that act on NumPy arrays, e.g., -``vectorize.__call__`` and various ``random.RandomState`` methods. Such classes -with methods are also found in other core libraries in the scientific Python -stack, e.g., distribution objects in scipy.stats and model objects in -scikit-learn. - -Overloads for such method could be fit into the ``__array_function__`` protocol -by establishing a standard way of inspecting the ``func`` argument, e.g., +Callable objects generated at runtime +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +NumPy has some APIs that define callable objects *dynamically*, such as +``vectorize`` and methods on ``random.RandomState`` object. Examples can +also be found in other core libraries in the scientific Python stack, e.g., +distribution objects in scipy.stats and model objects in scikit-learn. It would +be nice to be able to write overloads for such callables, too. This presents a +challenge for the ``__array_function__`` protocol, because unlike the case for +functions there is no public object in the ``numpy`` namespace to pass into +the ``func`` argument. + +We could potentially handle this by establishing an alternative convention +for how the ``func`` argument could be inspected, e.g., by using ``func.__self__`` to obtain the class object and ``func.__func__`` to return the unbound function object. However, some caution is in order, because -this could immesh what are currently implementation details as a permanent +this would immesh what are currently implementation details as a permanent features of the interface, such as the fact that ``vectorize`` is implemented as a class rather than closure, or whether a method is implemented directly or using a descriptor. Given the complexity and the limited use cases, we are also deferring on this issue for now, but we are confident that ``__array_function__`` could be -expanded to accomodate it in the future. +expanded to accomodate these use cases in the future if need be. Discussion ---------- |