On Fri, Sep 6, 2019 at 2:45 PM Ralf Gommers <ralf.gomm...@gmail.com> wrote: > There may be another very concrete one (that's not yet in the NEP): allowing > other libraries that consume ndarrays to use overrides. An example is > numpy.fft: currently both mkl_fft and pyfftw monkeypatch NumPy, something we > don't like all that much (in particular for mkl_fft, because it's the default > in Anaconda). `__array_function__` isn't able to help here, because it will > always choose NumPy's own implementation for ndarray input. With unumpy you > can support multiple libraries that consume ndarrays.
unumpy doesn't help with this either though, does it? unumpy is double-opt-in: the code using np.fft has to switch to using unumpy.fft instead, and then someone has to enable the backend. But MKL/pyfftw started out as opt-in – you could `import mkl_fft` or `import pyfftw` – and the whole reason they switched to monkeypatching is that they decided that opt-in wasn't good enough for them. >> The import numpy.overridable part is meant to help garner adoption, and to >> prefer the unumpy module if it is available (which will continue to be >> developed separately). That way it isn't so tightly coupled to the release >> cycle. One alternative Sebastian Berg mentioned (and I am on board with) is >> just moving unumpy into the NumPy organisation. What we fear keeping it >> separate is that the simple act of a pip install unumpy will keep people >> from using it or trying it out. > > Note that this is not the most critical aspect. I pushed for vendoring as > numpy.overridable because I want to not derail the comparison with NEP 30 et > al. with a "should we add a dependency" discussion. The interesting part to > decide on first is: do we need the unumpy override mechanism? Vendoring > opt-in vs. making it default vs. adding a dependency is of secondary interest > right now. Wait, but I thought the only reason we would have a dependency is if we're exporting it as part of the numpy namespace. If we keep the import as `import unumpy`, then it works just as well, without any dependency *or* vendoring in numpy, right? -n -- Nathaniel J. Smith -- https://vorpus.org _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion