[Numpy-discussion] NEP 31 — Context-local and global overrides of the NumPy API

Nathaniel Smith 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
SciPy/PyData stack...

> 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
thread.

Can you write separate NEPs for each of these? Some questions I'd like
to see addressed:

For fft:
- 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?

For random:
- 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?

For linalg:
- linalg already support __array_ufunc__ for overrides. Why do we need
a second override system? Isn't that redundant?

-n

-- 
Nathaniel J. Smith -- https://vorpus.org


More information about the NumPy-Discussion mailing list