<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Sep 10, 2019 at 10:53 AM Sebastian Berg <<a href="mailto:sebastian@sipsolutions.net">sebastian@sipsolutions.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Tue, 2019-09-10 at 17:28 +0200, Hameer Abbasi wrote:<br>
> On 07.09.19 22:06, Sebastian Berg wrote:<br>
> > <br>
> > Now for the end-users choosing one array-like over another, seems<br>
> > nicer<br>
> > as an implicit mechanism (why should I not mix sparse, dask and<br>
> > numpy<br>
> > arrays!?). This is the promise `__array_function__` tries to make.<br>
> > Unless convinced otherwise, my guess is that most library authors<br>
> > would<br>
> > strive for implicit support (i.e. sklearn, skimage, scipy).<br>
> You can, once you register the backend it becomes implicit, so all <br>
> backends are tried until one succeeds. Unless you explicitly say "I<br>
> do <br>
> not want another backend" (only/coerce=True).<br>
<br>
The thing here being "once you register the backend". Thus requiring at<br>
least in some form an explicit opt-in by the end user. Also, unless you<br>
use the with statement (with all the scoping rules attached), you<br>
cannot plug the coercion/creation hole left by `__array_function__`.<br></blockquote><div><br></div><div>The need for this is clear I think. We're discussion on the unumpy repo whether this can be done with a minor change to how unumpy works, or by having backend auto-register somehow on import. It should be possible without mandating that the end user has to explicitly do something, but needs some thought. Stay tuned.</div><div><br></div><div>Cheers,<br></div><div>Ralf<br></div><div><br></div></div></div>