Rename to callable objects generated at runtime

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
 ----------