<div dir="ltr"><div dir="ltr">On Wed, Dec 2, 2020 at 3:39 PM Sebastian Berg <<a href="mailto:sebastian@sipsolutions.net">sebastian@sipsolutions.net</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">1. If an argument is invalid in NumPy it is considered and error.<br>
   For example:<br>
<br>
       np.log(arr, my_weird_argument=True)<br>
<br>
   is always an error even if the `__array_function__` implementation<br>
   of `arr` would support it.<br>
   NEP 18 explicitly says that allowing forwarding could be done, but<br>
   will not be done at this time.<br></blockquote><div><br></div><div>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.</div><div><br></div><div>If you want to use my_weird_argument, you can call my_weird_library.log() instead.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">2. Arguments must only be forwarded if they are passed in:<br>
<br>
       np.mean(cupy_array)<br>
<br>
   ends up as `cupy.mean(cupy_array)` and not:<br>
<br>
       cupy.mean(cupy_array, axis=None, dtype=None, out=None,<br>
                 keepdims=False, where=True)<br>
<br>
   meaning that CuPy does not need to implement all of those kwargs and<br>
   NumPy can add new ones without breaking anyones code.<br></blockquote><div><br></div><div>My reasoning here was two-fold:</div><div>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</div><div>2. To make it easy for a library to implement "incomplete" versions of NumPy's API, by simply omitting arguments.</div><div><br></div><div>The idea was that NumPy's API is open to partial implementations, but not extension.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
3. NumPy should not check the *validity* of the arguments. For example:<br>
   `np.add.reduce(xarray, axis="long")` should probably work in xarray.<br>
   (`xarray.DataArray` does not actually implement the above.)<br>
   But a string cannot be used as an axis in NumPy.<br></blockquote><div><br></div><div>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 :).</div><div><br></div><div>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.</div></div></div>