[Numpy-discussion] asanyarray vs. asarray

Ralf Gommers ralf.gommers at gmail.com
Fri Oct 19 19:01:40 EDT 2018

On Fri, Oct 19, 2018 at 10:28 PM Ralf Gommers <ralf.gommers at gmail.com>

> On Fri, Oct 19, 2018 at 4:15 PM Hameer Abbasi <einstein.edison at gmail.com>
> wrote:
>> Hi!
>> On Friday, Oct 19, 2018 at 6:09 PM, Stephan Hoyer <shoyer at gmail.com>
>> wrote:
>> I don't think it makes much sense to change NumPy's existing usage of
>> asarray() to asanyarray() unless we add subok=True arguments (which default
>> to False). But this ends up cluttering NumPy's public API, which is also
>> undesirable.
>> Agreed so far.
> I'm not sure I agree. "subok" is very unpythonic; the average numpy
> library function should work fine for a well-behaved subclass (i.e. most
> things out there except np.matrix).
>> The preferred way to override NumPy functions going forward should be
>> __array_function__.
>> 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.
>> On Fri, Oct 19, 2018 at 8:13 AM Marten van Kerkwijk <
>> m.h.vankerkwijk at gmail.com> wrote:
>>> There are exceptions for `matrix` in quite a few places, and there now
>>> is warning for `maxtrix` - it might not be bad to use `asanyarray` and add
>>> an exception for `maxtrix`. Indeed, I quite like the suggestion by Eric
>>> Wieser to just add the exception to `asanyarray` itself - that way when
>>> matrix is truly deprecated, it will be a very easy change.
>> I don't quite understand this. Adding exceptions is not deprecation - we
> then may as well just rip np.matrix out straight away.
> What I suggested in the call about this issue is that it's not very
> effective to treat functions like percentile/quantile one by one without an
> overarching strategy. A way forward could be for someone to write an
> overview of which sets of functions now have asanyarray (and actually work
> with subclasses), which ones we can and want to change now, and which ones
> we can and want to change after np.matrix is gone. Also, some guidelines
> for new functions that we add to numpy would be handy. I suspect we've been
> adding new functions that use asarray rather than asanyarray, which is
> probably undesired.

Thanks Nathaniel and Stephan. Your comments on my other two points are both
clear and correct (and have been made a number of times before). I think
the "write an overview so we can stop making ad-hoc decisions and having
these discussions" is the most important point I was trying to make though.
If we had such a doc and it concluded "hence we don't change anything,
__array_function__ is the only way to go" then we can just close PRs like
https://github.com/numpy/numpy/pull/11162 straight away.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20181019/55d77c56/attachment.html>

More information about the NumPy-Discussion mailing list