[Numpy-discussion] NEP 37: A dispatch protocol for NumPy-like modules

Sebastian Berg sebastian at sipsolutions.net
Fri Apr 10 09:01:32 EDT 2020

On Fri, 2020-04-10 at 12:27 +0200, Ralf Gommers wrote:
> > 3. I added features to allow transitioning::
> >
> >       get_array_module(*arrays, modules="numpy",
> >             future_modules=("dask.array", "cupy"), fallback="warn")
> >
> >    Will give FutureWarning/DeprecationWarning where necessary, in
> the
> >    above "numpy" is supported, dask and cupy are supported but not
> >    enabled by default. `None` works to say "all modules".
> >    Once the transition is done, just move dask and cupy into
> `modules`
> >    and remove `fallback=None`.
> >
> So future_modules explicitly excludes compatible libraries that are
> not
> listed. Why would you want anyone to do that? I don't understand
> "supported
> but not enabled", and it looks undesirable to me to special-case any
> library in this mechanism.

We hav two (or three) types of modules (either could be "all").

1. Supported modules that we dispatch to.
2. Modules that are supported but will be dispatched to by default only
   in the future. So if the user got a future_module, they will get a
   FutureWarning. They have to chose to cast the inputs or opt-in to
   the future behaviour.
3. Unsupported modules: If this is resolved it is an error. I currently
   assume that this does not need to be a negative list.

You need to distinguish those somehow, since you need a way to
transition. Even if you expect that modules would always be *all*
modules, `numpy` is still the only accepted module originally.

So, as I said, `future_modules` is only about transitioning and
enabling `FutureWarning`s. Does not have to live there, but we need a
way to transition.
These options do not have to be handled by us, it only helps here with
having context managers to opt-in to new behaviour, and maybe to get an
idea for how transitions can look like.
Alternatively, we could all to create project specific context managers
to do the same and avoid possible scoping issues even more.

- Sebastian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20200410/af5d9569/attachment-0001.sig>

More information about the NumPy-Discussion mailing list