[Numpy-discussion] NEP 31 — Context-local and global overrides of the NumPy API
njs at pobox.com
Sat Sep 7 19:15:50 EDT 2019
On Fri, Sep 6, 2019 at 11:04 PM Ralf Gommers <ralf.gommers at gmail.com> wrote:
> Vendoring means "include the code". So no dependency on an external package. If we don't vendor, it's going to be either unused, or end up as a dependency for the whole SciPy/PyData stack.
If we vendor it then it also ends up as a dependency for the whole
> Actually, now that we've discussed the fft issue, I'd suggest to change the NEP to: vendor, and make default for fft, random, and linalg.
There's no way we can have an effective discussion of duck arrays, fft
backends, random backends, and linalg backends all at once in a single
Can you write separate NEPs for each of these? Some questions I'd like
to see addressed:
- fft is an entirely self-contained operation, with no interactions
with the rest of the system; the only difference between
implementations is speed. What problems are caused by monkeypatching,
and how is uarray materially different from monkeypatching?
- I thought the new random implementation with pluggable generators
etc. was supposed to solve this problem already. Why doesn't it?
- The biggest issue with MKL monkeypatching random is that it breaks
stream stability. How does the uarray approach address this?
- linalg already support __array_ufunc__ for overrides. Why do we need
a second override system? Isn't that redundant?
Nathaniel J. Smith -- https://vorpus.org
More information about the NumPy-Discussion