<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 5:17 AM 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 Thu, 2020-04-09 at 13:52 +0200, Ralf Gommers wrote:<br>
> On Thu, Apr 9, 2020 at 12:02 AM Sebastian Berg <<br>
> <a href="mailto:sebastian@sipsolutions.net" target="_blank">sebastian@sipsolutions.net</a>><br>
> wrote:<br>
> <br>
<snip><br>
> > <br>
> <br>
> I think it would be nice to have a separate NEP 37 implementation<br>
> outside<br>
> of NumPy to play with. Unlike __array_function__, I don't think it<br>
> has to<br>
> go into NumPy immediately. This avoids the whole "experimental API"<br>
> issue,<br>
<br>
Fair enough, I have created a hopefully working start here:<br>
<br>
<a href="https://github.com/seberg/numpy_dispatch" rel="noreferrer" target="_blank">https://github.com/seberg/numpy_dispatch</a><br>
<br>
(this is not tested much at all yet, so it could be very buggy).<br></blockquote><div><br></div><div>Thanks!</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>
There are a couple of additional features that I added.<br>
<br>
1. A global opt-in (it is impossible to opt-out once opted in!)<br>
2. A local opt-in (to guarantee opt-in if global flag is not set)<br>
3. I added features to allow transitioning::<br>
<br>
      get_array_module(*arrays, modules="numpy",<br>
            future_modules=("dask.array", "cupy"), fallback="warn")<br>
<br>
   Will give FutureWarning/DeprecationWarning where necessary, in the<br>
   above "numpy" is supported, dask and cupy are supported but not<br>
   enabled by default. `None` works to say "all modules".<br>
   Once the transition is done, just move dask and cupy into `modules`<br>
   and remove `fallback=None`.<br></blockquote><div><br></div><div>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.<br></div><div><br></div><div>Cheers,</div><div>Ralf<br></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">
4. If there are FutureWarnings/DeprecationWarnigs the user needs to be<br>
   able to opt-in to future behaviour. Opting out can be done by<br>
   casting inputs. Opting-in is done using::<br>
<br>
      with future_dispatch_behavior():<br>
          call_library_function()<br>
<br>
Obviously, we may not want these features, but I was curious how we<br>
could provide the tools to allow clean transitions.<br>
<br>
Both context managers should be thread-safe, but I did not test that.<br>
<br>
The best try would probably be cupy and sklearn again, so I will give a<br>
ping on the sklearn PR. To make that easier, I tried to hack a bit of a<br>
"util" to allow testing (please scroll down on the readme on github).<br>
<br>
Best,<br>
<br>
Sebastian<br>
<br>
<br>
<br>
> it would be quite useful to test this with, e.g., CuPy + scikit-learn<br>
> without being stuck with any decisions in a released NumPy version.<br>
> Also<br>
> makes switching on/off very easy for users, just (don't) `pip install<br>
> numpy-array-module`.<br>
> <br>
> Cheers,<br>
> Ralf<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>