[Numpy-discussion] asanyarray vs. asarray
shoyer at gmail.com
Fri Oct 19 18:46:52 EDT 2018
> 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
My hope is that __array_function__ will finally let us put a stop to this
by offering a better alternative to subclassing.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the NumPy-Discussion