<div dir="ltr"><br><div class="gmail_quote"><span class=""></span><div>This in certainly true in general, but given the complete flexibility of __array_function__ there's no way we can make every check convenient. The best we can do is make it easy to handle the common cases, where the argument position does not matter.</div><span class=""><div><br></div><div>I think those cases may not be as common as you think - most functions are not like `concatenate` & co... Indeed, it might be good to add some other examples to the NEP. Looing at the list of functions which do not work with Quantity currently: Maybe `np.dot`, `np.choose`, and `np.vectorize`?<br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>Possibly, a solution would rely on the same structure as used for the "dance". But as a general point, I don't see the advantage of passing types rather than arguments - less information for no benefit. <br></div></div></div></div></blockquote><div><br></div></span><div>> Maybe this is premature optimization, but there will certainly be fewer unique types than arguments to check for types. I suspect this may make for a noticeable difference in performance in use cases involving a large number of argument.</div><div><br></div><div>One also needs to worry about the cost of contructing `types`, though I guess this could be minimal if it is a `set`. Or should it be the keys of a `dict`, with the value something meaningful that has to be calculated anyway (like a list of sequence numbers); this may all depend a bit on the implementation of "dance" - the information it gathers might as well get passed on.<br></div><div><br></div><div>> For example, suppose np.concatenate() is called on a list of 10,000 dask arrays. Now dask.array.Array.__array_<wbr>function__ needs to check all arguments to decide whether it can use dask.array.concatenate() or needs to return NotImplemented. By using the `types` argument, it only needs to do isinstance() checks on the single argument in `types`, rather than all 10,000 overloaded function arguments<br><br></div><div>It is probably a good idea to add some of these considerations to the NEP.<br><br></div><div>-- Marten<br></div></div></div>