[Numpy-discussion] NEP 31 — Context-local and global overrides of the NumPy API

Ralf Gommers ralf.gommers at gmail.com
Wed Sep 11 18:53:11 EDT 2019

On Tue, Sep 10, 2019 at 10:53 AM Sebastian Berg <sebastian at sipsolutions.net>

> On Tue, 2019-09-10 at 17:28 +0200, Hameer Abbasi wrote:
> > On 07.09.19 22:06, Sebastian Berg wrote:
> > >
> > > Now for the end-users choosing one array-like over another, seems
> > > nicer
> > > as an implicit mechanism (why should I not mix sparse, dask and
> > > numpy
> > > arrays!?). This is the promise `__array_function__` tries to make.
> > > Unless convinced otherwise, my guess is that most library authors
> > > would
> > > strive for implicit support (i.e. sklearn, skimage, scipy).
> > You can, once you register the backend it becomes implicit, so all
> > backends are tried until one succeeds. Unless you explicitly say "I
> > do
> > not want another backend" (only/coerce=True).
> The thing here being "once you register the backend". Thus requiring at
> least in some form an explicit opt-in by the end user. Also, unless you
> use the with statement (with all the scoping rules attached), you
> cannot plug the coercion/creation hole left by `__array_function__`.

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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20190911/53f2317f/attachment.html>

More information about the NumPy-Discussion mailing list