On Fri, Apr 10, 2020 at 3:03 PM Sebastian Berg <sebast...@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@python.org
> https://mail.python.org/mailman/listinfo/numpy-discussion
>
_______________________________________________
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion
