What's the difference from simply import unumpy? Also, I think it's very confusing that import numpy.overridable is an alias to a different top-level package with a completely different name.

What we're proposing here is that a completed version of unumpy be vendored into NumPy as numpy.overridable, with a soft dependency on unumpy in case it exists.

then it should be explicit where this comes from and not a top-level import: from numpy.uarray import overridable as unumpy or even better from numpy.uarray import unumpy.

My reasoning was that people reach for np whenever using NumPy, so importing it as np keeps familiarity as the API is mirrored.

I've changed the import to from numpy import overridable as unumpy.

SciPy FFT already uses it, but I did not notice too much discussion on scipy (maybe I missed it). And the use case is probably quite a lot simpler.

simpler in some ways, but not strictly simpler. for example, there are multiple backends there that all consume numpy arrays. a protocol like __array_function__ that's attached to the array itself cannot deal with that.

It might be worth noting that agreeing on one protocol/library (for the most part) means that it is OK if the need for new overriding protocols is not within numpy itself, but within the ecosystem.

I'm not sure I got your point here. can you expand on this a bit?

simpler in some ways, but not strictly simpler. for example, there are multiple backends there that all consume numpy arrays. a protocol like array_function that's attached to the array itself cannot deal with that.

Right, it is different. I am actually very much interested in how the two would/can interact (but I already asked that a few times in the other comments I think).

I'm not sure I got your point here. can you expand on this a bit?

Well, if Scipy uses this, and say scikit-learn uses uarray then you at least have the nice effect that library author can learn the same tool for many different things (and more users means better docs, etc.). Maybe not much of a point.

Ah yes. Indeed, uarray is meant as a generic backend creation mechanism. There's not so many of those to choose from in Python land. Most backends are ad-hoc and specific to one library.

I am actually very much interested in how the two would/can interact

It'll be nested - if there's a unumpy function that's also covered by __array_ufunc__ or __array_function__, then those protocols will be used like normal when the numpy backend to unumpy is used. In case another backend is used (dask/sparse/etc), then of course the protocols do nothing.

Yes, there has to be an opt-in/new API somewhere, but what are the real advantages of having it inside numpy proper? As far as I can see:

1. `uarray` (really more general library than "array", which is fine) is the toolchain, a `unumpy` may want to vendor it to ensure stable API.
   
   * If the proposal is to try import the non-vendored version, I am actually a bit less sure about that.

2. `unumpy` a reduced numpy-like API, which provides backend switching possibilities based on `uarray`.

An explicit import with matching API is of course the cleanest (and only reasonable thing). What I am missing is an argument why it should live within the numpy namespace or even within numpy at all and not just in the numpy organization (with documentation pointing it out).

Also maybe to be clear. Unlike scipy.fft the main target of unumpy I think are downstream packages such as scikit-learn or so, to allow them to easier support multiple array-likes with a single code base. These already have a big number of dependencies, so it is worth vendoring in the numpy namespace?

While I don't mind either way, I'm +1 on moving unumpy into the NumPy repo org and +0.7 on vendoring.