> > I think we should “soft support” i.e. allow but consider unsupported, the >> case where one of NumPy’s functions is implemented in terms of others and >> “passing through” an array results in the correct behaviour for that array. >> > > I don't think we have or want such a concept as "soft support". We intend > to not break anything that now has asanyarray, i.e. it's supported and > ideally we have regression tests for all such functions. For anything we > transition over from asarray to asanyarray, PRs should come with new tests. >
The problem with asanyarray() is that there isn't any well defined subclass API for NumPy, beyond "mostly works like a NumPy array." If every NumPy subclass strictly obeyed the Liskov Substitution Principle asanyarray() would be fine, but in practice every subclass I've encountered deviates from the behavior of numpy.ndarray in some way. The means the NumPy codebase has ended up littered with hacks/workarounds to support various specific subclasses, and new subclasses still don't work reliably. This makes it challenging to change existing code. For an example of how bad this is gotten, look at all the work-arounds I had to add to support np.testing.assert_array_equal() on ndarray subclasses in this recent PR: https://github.com/numpy/numpy/pull/12119 My hope is that __array_function__ will finally let us put a stop to this by offering a better alternative to subclassing.
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion
