On Mon, Feb 22, 2021 at 8:52 PM Sebastian Berg <sebast...@sipsolutions.net> wrote:
> On Mon, 2021-02-22 at 20:16 +0100, Ralf Gommers wrote: > > <snip> > > > > > > > It seems the current idea is to create a new NumPy array subclass. > > > That > > > sounds good, but I am a bit worried how that is going to interact > > > with > > > actual NumPy arrays. > > > > > > > Not a subclass! If you got that impression, I should clarify the > > text. The > > Sorry, you do write "wraps a numpy.ndarray", I am not sure why I got > the subclass idea when reading it yesterday. > > But, in that case maybe you should just implement it as: > > def somefunc(x): > # do whatever checks needed here for, e.g., input validation > # then call the native numpy implementation: > x = as_numpy_array(x) > result = np.somefunc(x) > return as_minimal(x) > > and not even use the `._implementation`? That makes sense. It's like doing a double asarray, but you get the fast path in __array_function__ I guess small issue is that > we don't have a way to call `as_ndarray` on all relevant inputs > conveniently. Why not? The input should be very well-defined, basically just instances of the new array object. Note that you cannot pass lists, generators, or other such types. In most cases it will be straight forward though. > > I assume you need your own `as_numpy_array` call, to reject ndarray- > subclasses, that `_implementation` will allow to pass through. > > > > > > > Related to that: how important is it to keep that namespace a > > > "minimal" > > > implementation, rather than a "conforming" one? For example, would > > > you > > > want to reject `numpy_api.array([1, 2, 3, 4], dtype="i,i")`? Or > > > just > > > `dtype="complex128"`? > > > > > > > Yes, I'd definitely want to reject that. Format strings are terrible. > > > Agreed, I guess I am wondering whether we can find a good solution that > does not involve writing stubs around 140 functions with more strict > input validation. > But maybe it is also not particularly difficult or churn to do... Or > even automate, e.g. from the typing stubs. > I think it's easy to do, and better than something "smart". Also note that there are no typing stubs, the type annotations are clean enough that they can be added inline, which is much nicer than stubs. > > > > > Maybe I got the wrong impression though. Is the aim for a minimal > > > implementation, but you are OK as long as it is a conforming one? > > > > > > > In principle we're okay with a conforming one that's a superset of > > what is > > in the standard. But I think we'd only want to do that if creating a > > minimal one turns out to be difficult. Having the minimal required > > set is > > much nicer when one wants to write portable code. Because then you > > can do > > so without checking the docs whether any object/method is in > > "minimal" or > > in "extended". > > > > Right, you would like to have a minimal implementation somewhere. > Having it in NumPy could be convenient, although not strictly > necessary. > That was my original thinking - just reuse `np.ndarray`, and have the "minimal" thing as a standalone implementation in a new package. But that's more work, and less nice. After getting used to the idea of a second array object, I'm actually much happier with having it in numpy. > > <snip> > > > > > > Besides `_implementation` usually does support array subclasses and > > > may > > > still dispatch again internally at this time! > > > > > > > What, it dispatches again? That seems very suboptimal. If there's no > > clean > > way to avoid a dispatch, it may make sense to just check array inputs > > for > > the presence of __array_function__ and raise an exception if it's > > present. > > > > > I do not think our functions where ever rewritten to only use e.g. > `._implementation()` internally. I am not even quite certain that would > be correct for subclasses. > > It is annoying that you may have to struggle with it here to do > something that is different from the implicit dispatchers. But on the > up-side a clear solution would be helpful in any case. > Agreed. Cheers, Ralf
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion
