[Numpy-discussion] Rules for argument parsing/forwarding in __array_function__ and __array_ufunc__

[Stephan Hoyer]

On Wed, Dec 2, 2020 at 3:39 PM Sebastian Berg <sebastian at sipsolutions.net>
wrote:

> 1. If an argument is invalid in NumPy it is considered and error.
>    For example:
>
>        np.log(arr, my_weird_argument=True)
>
>    is always an error even if the `__array_function__` implementation
>    of `arr` would support it.
>    NEP 18 explicitly says that allowing forwarding could be done, but
>    will not be done at this time.
>

>From my perspective, this is a good thing: it ensures that NumPy's API is
only used for features that exist in NumPy. Otherwise I can imagine causing
considerable confusion.

If you want to use my_weird_argument, you can call my_weird_library.log()
instead.


> 2. Arguments must only be forwarded if they are passed in:
>
>        np.mean(cupy_array)
>
>    ends up as `cupy.mean(cupy_array)` and not:
>
>        cupy.mean(cupy_array, axis=None, dtype=None, out=None,
>                  keepdims=False, where=True)
>
>    meaning that CuPy does not need to implement all of those kwargs and
>    NumPy can add new ones without breaking anyones code.
>

My reasoning here was two-fold:
1. To avoid the unfortunate situation for functions like np.mean(), where
NumPy jumps through considerable hoops to avoid passing extra arguments in
an ad-hoc way to preserve backwards compatibility
2. To make it easy for a library to implement "incomplete" versions of
NumPy's API, by simply omitting arguments.

The idea was that NumPy's API is open to partial implementations, but not
extension.


> 3. NumPy should not check the *validity* of the arguments. For example:
>    `np.add.reduce(xarray, axis="long")` should probably work in xarray.
>    (`xarray.DataArray` does not actually implement the above.)
>    But a string cannot be used as an axis in NumPy.
>

I don't think libraries should be encouraged to abuse NumPy's API to mean
something else. Certainly I would not use this in xarray :).

If we could check the validity of arguments cheaply, that would be fine by
me. But I didn't think it was worth adding overhead to every function call.
Perhaps type annotations could be relied on for these sorts of checks? I am
pretty happy considering not checking the validity of arguments to be an
implementation detail for now.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.python.org/pipermail/numpy-discussion/attachments/20201205/4031d06f/attachment.html>