On Fri, Sep 6, 2019 at 11:04 PM Ralf Gommers <ralf.gomm...@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 _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion
