<div dir="ltr"><div dir="auto"><div><div class="gmail_extra"><div class="gmail_quote">On Nov 6, 2017 4:19 PM, "Chris Barker" <<a href="mailto:chris.barker@noaa.gov" target="_blank">chris.barker@noaa.gov</a>> wrote:<br type="attribution"><blockquote class="m_4333048133026320357quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div class="m_4333048133026320357quoted-text">On Sat, Nov 4, 2017 at 6:47 AM, Marten van Kerkwijk <span dir="ltr"><<a href="mailto:m.h.vankerkwijk@gmail.com" target="_blank">m.h.vankerkwijk@gmail.com</a>></span> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="m_4333048133026320357quoted-text"><br>
You just summarized excellently why I'm on a quest to change `asarray`<br></div>
to `asanyarray` within numpy</blockquote><div><br></div><div>+1 -- we should all be using asanyarray() most of the time. </div></div></div></div></blockquote></div></div></div><div dir="auto"><br></div><div dir="auto">The problem is that if you use 'asanyarray', then you're claiming that your code works correctly for:</div><div dir="auto">- regular ndarrays</div><div dir="auto">- np.matrix</div><div dir="auto">- <a href="http://np.ma" target="_blank">np.ma</a> masked arrays</div><div dir="auto">- and every third party subclass, regardless of their semantics, regardless of whether you've heard of them or not<br></div><div dir="auto"><br></div><div dir="auto">If subclasses followed the Liskov substitution principle, and had different internal implementations but the same public ("duck") API, then this would be fine. But in practice, numpy limitations mean that ndarrays subclasses have to have the same internal implementation, so the only reason to make an ndarray subclass is if you want to make something with a different public API. Basically the whole system is designed for subclasses to be incompatible.<br></div><div dir="auto"><br></div><div dir="auto">The end result is that if you use asanyarray, your code is definitely wrong, because there's no way you're actually doing the right thing for arbitrary ndarray subclasses. But if you don't use asanyarray, then yeah, that's also wrong, because it won't work on mostly-compatible subclasses like astropy's. Given this, different projects reasonably make different choices -- it's not just legacy code that uses asarray. In the long run we obviously need to come up with new options that don't have these tradeoffs (that's why we want to let units to to dtypes, implement methods like __array_ufunc__ to enable duck arrays, etc.) let's try to be sympathetic to other projects that are doing their best :-).<br></div></div><div><br></div><div>-n<br></div>
</div>