<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Apr 10, 2020 at 7:18 PM 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 Fri, 2020-04-10 at 18:19 +0200, Ralf Gommers wrote:<br>
> On Fri, Apr 10, 2020 at 3:03 PM Sebastian Berg <<br>
> <a href="mailto:sebastian@sipsolutions.net" target="_blank">sebastian@sipsolutions.net</a>><br>
> wrote:<br>
> <br>
> > On Fri, 2020-04-10 at 12:27 +0200, Ralf Gommers wrote:<br>
> > > > 3. I added features to allow transitioning::<br>
> > > > <br>
> > > >       get_array_module(*arrays, modules="numpy",<br>
> > > >             future_modules=("dask.array", "cupy"),<br>
> > > > fallback="warn")<br>
> > > > <br>
> > > >    Will give FutureWarning/DeprecationWarning where necessary,<br>
> > > > in<br>
> > > the<br>
> > > >    above "numpy" is supported, dask and cupy are supported but<br>
> > > > not<br>
> > > >    enabled by default. `None` works to say "all modules".<br>
> > > >    Once the transition is done, just move dask and cupy into<br>
> > > `modules`<br>
> > > >    and remove `fallback=None`.<br>
> > > > <br>
> > > <br>
> > > So future_modules explicitly excludes compatible libraries that<br>
> > > are<br>
> > > not<br>
> > > listed. Why would you want anyone to do that? I don't understand<br>
> > > "supported<br>
> > > but not enabled", and it looks undesirable to me to special-case<br>
> > > any<br>
> > > library in this mechanism.<br>
> > <br>
> > We hav two (or three) types of modules (either could be "all").<br>
> > <br>
> <br>
> I think we only have modules that implement __array_module__, and<br>
> ones that<br>
> don't.<br>
> <br>
> <br>
> > 1. Supported modules that we dispatch to.<br>
> > 2. Modules that are supported but will be dispatched to by default<br>
> > only<br>
> >    in the future. So if the user got a future_module, they will get<br>
> > a<br>
> >    FutureWarning. They have to chose to cast the inputs or opt-in<br>
> > to<br>
> >    the future behaviour.<br>
> > 3. Unsupported modules: If this is resolved it is an error. I<br>
> > currently<br>
> >    assume that this does not need to be a negative list.<br>
> > <br>
> > You need to distinguish those somehow, since you need a way to<br>
> > transition. Even if you expect that modules would always be *all*<br>
> > modules, `numpy` is still the only accepted module originally.<br>
> > <br>
> > So, as I said, `future_modules` is only about transitioning and<br>
> > enabling `FutureWarning`s. Does not have to live there, but we need<br>
> > a<br>
> > way to transition.<br>
> > <br>
> <br>
> Sorry, I still don't get it - transition what? You seem to be<br>
> operating on<br>
> the assumption that the users of get_array_module want or need to<br>
> control<br>
> which numpy-like libraries they allow and which they don't. That<br>
> seems<br>
> fundamentally wrong. How would you treat, for example, an array<br>
> library<br>
> that is developed privately inside some company?<br>
> <br>
<br>
Well, you still need to transition from NumPy -> allow everything, so<br>
for now please just ignore that part if you like and use/assume:<br>
<br>
   get_array_module(...,<br>
       modules="numpy", future_modules=None, fallback="warn")<br>
<br>
during the transition, and:<br>
<br>
   get_array_module(...)<br>
<br>
after it. After all this is a draft-project right now, so it is just as<br>
much about trying out what can be done.<br>
It is not unlikely that this transition burden will be put more on the<br>
library in any case, but it shows that it can be done.<br>
<br>
<br>
As to my "fundamentally wrong" assumption. Should libraries goal be to<br>
support everything? Definitely!<br>
<br>
But... I do not want to make that decision for libraries, so I if<br>
library authors tell me that they have no interest in it, all the<br>
better. Until then I am more than happy to keep that option on the<br>
table. If just as a thought for library authors to consider their<br>
options.<br>
<br>
Possible, brainstorming, reasons could be:<br>
<br>
1. Say I currently heavily use cython code, so I am limited to NumPy<br>
(or at least arrays that can expose a buffer/`__array_interface__`).<br>
Now if someone adds a CUDA implementation, I would support cupy arrays,<br>
but not distributed arrays.<br>
I admit maybe checking that at function entry like this is the wrong<br>
approach there.<br></blockquote><div><br></div><div>If you need a particular feature, then checking for that feature (e.g. `hasattr(__array_interface__)`, and same for __cuda_array_interface__) seems like the right thing to do.</div><div><br></div><div>Ralf</div><div><br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
2. To limit to certain types is to say "We know (and test) that our<br>
library works with xarray, Dask, NumPy, and CuPy". Now you can say that<br>
is also a misconception, because if you stick to just NumPy API you<br>
should know that it will "just work" with everything. But in practice<br>
it seems like it might happen?<br>
In that case you may want to actually allow any odd array and just put<br>
a warning, a bit like the transition warnings I put in for testing.<br>
<br>
<br>
---<br>
<br>
There are two other things I am wondering about.<br>
<br>
1. Subclasses may want to return their superclasses module (even by<br>
default?), in which case their behaviour depends on the superclass<br>
module behaviour. Further a library would need to use `np.asanyarray()`<br>
to prevent the subclass from being cast to the superclass.<br>
<br>
2. There is one transition that does not quite exists. What if an<br>
array-like starts implementing or expands `array-module`?<br>
That seems fine, but in that case the array-like will have to provide<br>
the `opt-in` context manager with a FutureWarning.<br>
The transition from no `__array_module__` to implementing it may need<br>
some thought, but I expect it is fine: The array-like simply always<br>
gives a FutureWarning, although it cannot know what will actually<br>
happen in the future (no change, error, or array-like takes control).<br>
<br>
- Sebastian<br>
<br>
<br>
> Cheers,<br>
> Ralf<br>
> <br>
> <br>
> <br>
> > These options do not have to be handled by us, it only helps here<br>
> > with<br>
> > having context managers to opt-in to new behaviour, and maybe to<br>
> > get an<br>
> > idea for how transitions can look like.<br>
> > Alternatively, we could all to create project specific context<br>
> > managers<br>
> > to do the same and avoid possible scoping issues even more.<br>
> > <br>
> > - Sebastian<br>
> > _______________________________________________<br>
> > NumPy-Discussion mailing list<br>
> > <a href="mailto:NumPy-Discussion@python.org" target="_blank">NumPy-Discussion@python.org</a><br>
> > <a href="https://mail.python.org/mailman/listinfo/numpy-discussion" rel="noreferrer" target="_blank">https://mail.python.org/mailman/listinfo/numpy-discussion</a><br>
> > <br>
> <br>
> _______________________________________________<br>
> NumPy-Discussion mailing list<br>
> <a href="mailto:NumPy-Discussion@python.org" target="_blank">NumPy-Discussion@python.org</a><br>
> <a href="https://mail.python.org/mailman/listinfo/numpy-discussion" rel="noreferrer" target="_blank">https://mail.python.org/mailman/listinfo/numpy-discussion</a><br>
<br>
_______________________________________________<br>
NumPy-Discussion mailing list<br>
<a href="mailto:NumPy-Discussion@python.org" target="_blank">NumPy-Discussion@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/numpy-discussion" rel="noreferrer" target="_blank">https://mail.python.org/mailman/listinfo/numpy-discussion</a><br>
</blockquote></div></div>