<div dir="ltr"><div dir="ltr">On Thu, Apr 25, 2019 at 12:46 PM Marten van Kerkwijk <<a href="mailto:m.h.vankerkwijk@gmail.com">m.h.vankerkwijk@gmail.com</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"><div dir="ltr"><div>It seems we are adding to the wishlist!  I see four so far:</div><div>1. Exposed in API, can be overridden with __array_ufunc__</div><div>2. One that converts everything to ndarray (or subclass); essentially the current implementation;</div><div>3. One that does asduckarray</div><div>4. One that assumes all arguments are arrays.</div><div><br></div><div>Maybe handiest would be if there is a method to coerce all relevant arguments with a function of one's choice? I.e., in the example of Stephan, one would have</div><div>```<br></div><div>if function in JUST_COERCE:</div><div>    coerced_args, coerced_kwargs = function.__coerce__(np.asanyarray, *args, **kwargs)</div><div>    return function.__implementation__(*coerced_args, **coerced_kwargs)<br></div><div>```</div><div>Actually, this might in fact work with the plan proposed here, if we allow for an extra, optional kwarg that contains the coercion function, that is</div><div>```</div><div>    return function.__implementation__(*args, coercion_function=np.asanyarray, **kwargs)</div><div>```</div><div></div><div><br></div><div>The possible advantage of this over yet more dunder methods is that one can fine-tune the extent to which something has to mimic an array properly (e.g., run `asanyarray` only if `shape` is not present).</div></div></blockquote><div><br></div><div>I do like the look of this, but keep in mind that there is a downside to exposing the implementation of NumPy functions -- now the implementation details become part of NumPy's API. I suspect we do not want to commit ourselves to never changing the implementation of NumPy functions, so at the least this will need careful disclaimers about non-guarantees of backwards compatibility.</div><div><br>But for now, I would love to pick a name for "essentially the current implementation", which is something that would make a big difference for near-term NEP-18 use cases. Some options:</div><div>__skipping_array_function__</div><div>__coercive_implementation__<br></div><div>__asarray_implementaiton__</div><br class="gmail-Apple-interchange-newline"><div>The last two are not quite right, since there is some legacy dispatching to methods. Maybe __skipping_array_function__ is the best?</div><div><br></div><div>Whatever we pick, we can always make it an alias later, e.g., for func.__implementation__(*args, coercion_function=np.asanyarray, **kwargs).</div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>It would be nice, though, if we could end up with also option 4 being available, if only because code that just can assume ndarray will be easiest to read.<br></div></div></blockquote><div><br></div><div>This could perhaps just be coercion_function=None? Or maybe we want to keep around coercion_function=None for "do whatever ad-hoc coercion NumPy current does"?</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"><div dir="ltr"><div></div><div><br></div><div>All the best,</div><div><br></div><div>Marten<br></div></div>
_______________________________________________<br>
NumPy-Discussion mailing list<br>
<a href="mailto:NumPy-Discussion@python.org" target="_blank">NumPy-Discussion@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/numpy-discussion" rel="noreferrer" target="_blank">https://mail.python.org/mailman/listinfo/numpy-discussion</a><br>
</blockquote></div></div>