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

[Ralf Gommers]

On Fri, Apr 10, 2020 at 3:03 PM Sebastian Berg <sebastian at sipsolutions.net>
wrote:

> 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").
>

I think we only have modules that implement __array_module__, and ones that
don't.


> 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.
>

Sorry, I still don't get it - transition what? You seem to be operating on
the assumption that the users of get_array_module want or need to control
which numpy-like libraries they allow and which they don't. That seems
fundamentally wrong. How would you treat, for example, an array library
that is developed privately inside some company?

Cheers,
Ralf



> 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
> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion at python.org
> https://mail.python.org/mailman/listinfo/numpy-discussion
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20200410/34c63d18/attachment.html>