<!DOCTYPE html><html><head><title></title><style type="text/css">p.MsoNormal,p.MsoNoSpacing{margin:0}</style></head><body><div>Hi Sebastian,</div><div><br></div><div>Looking at these three rules, they all seem to stem from one simple question: do we desire for a single code snippet to be runnable on multiple array implementations?<br></div><div><br></div><div>On Wed, Dec 2, 2020, at 15:34, Sebastian Berg wrote:<br></div><blockquote type="cite" id="qt" style=""><div>1. If an argument is invalid in NumPy it is considered and error.<br></div><div> For example:<br></div><div><br></div><div> np.log(arr, my_weird_argument=True)<br></div><div><br></div><div> is always an error even if the `__array_function__` implementation<br></div><div> of `arr` would support it.<br></div><div> NEP 18 explicitly says that allowing forwarding could be done, but<br></div><div> will not be done at this time.<br></div></blockquote><div><br></div><div>Relaxing this rule will mean that code working for one array implementation (which has this keyword) may not work for another.<br></div><div><br></div><blockquote type="cite" id="qt" style=""><div>2. Arguments must only be forwarded if they are passed in:<br></div><div><br></div><div> np.mean(cupy_array)<br></div><div><br></div><div> ends up as `cupy.mean(cupy_array)` and not:<br></div><div><br></div><div> cupy.mean(cupy_array, axis=None, dtype=None, out=None,<br></div><div> keepdims=False, where=True)<br></div><div><br></div><div> meaning that CuPy does not need to implement all of those kwargs and<br></div><div> NumPy can add new ones without breaking anyones code.<br></div></blockquote><div><br></div><div>This may ultimately make it harder for array implementors (they will only see errors once someone tries to pass in an argument that they forgot to implement). Perhaps better to pass all so they know what they're dealing with?<br></div><div><br></div><blockquote type="cite" id="qt" style=""><div>3. NumPy should not check the *validity* of the arguments. For example:<br></div><div> `np.add.reduce(xarray, axis="long")` should probably work in xarray.<br></div><div> (`xarray.DataArray` does not actually implement the above.)<br></div><div> But a string cannot be used as an axis in NumPy.<br></div></blockquote><div><br></div><div>Getting back to the original question: if this code is to be run on multiple implementations, we should ensure that no strange values pass through.<br></div><div><br></div><div>Personally, I like the idea of a single API that works on multiple backends. As such, I would 1) not pass through unknown arguments, 2) always pass through all arguments, and 3) validate inputs to each call.<br></div><div><br></div><div>Best regards,<br></div><div>Stéfan<br></div><div><br></div></body></html>