<div dir="ltr">Here's a PR with a different dicsussion of __array__:<div><br></div><div><a href="https://github.com/numpy/numpy/pull/14529">https://github.com/numpy/numpy/pull/14529</a><br></div><div><br></div><div>-CHB</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Sep 16, 2019 at 3:23 PM Chris Barker <<a href="mailto:chris.barker@noaa.gov">chris.barker@noaa.gov</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">OK -- I *finally* got it:<div><br></div><div>when you pass an arbitrary object into np.asarray(), it will create an array object scalar with the object in it.</div><div><br></div><div>So yes, I can see that you may want to raise a TypeError instead, so that users don't get an object array scalar when they wre expecting to get an array-like object.</div><div><br></div><div>So it's probably a good idea to recommend that when a class implements __dauckarray__ that it also implements __array__, which can either raise an exception or return and ndarray.</div><div><br></div><div>-CHB</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Sep 16, 2019 at 3:11 PM Chris Barker <<a href="mailto:chris.barker@noaa.gov" target="_blank">chris.barker@noaa.gov</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr">On Mon, Sep 16, 2019 at 2:27 PM Stephan Hoyer <<a href="mailto:shoyer@gmail.com" target="_blank">shoyer@gmail.com</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr">On Mon, Sep 16, 2019 at 1:45 PM Peter Andreas Entschev <<a href="mailto:peter@entschev.com" target="_blank">peter@entschev.com</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">What would be the use case for a duck-array to implement __array__ and<br>
return a NumPy array? </blockquote><div></div></div></div></blockquote><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div>Dask arrays are a good example. They will want to implement __duck_array__ (or whatever we call it) because they support duck typed versions of NumPy operation. They also (already) implement __array__, so they can converted into NumPy arrays as a fallback. This is convenient for moderately sized dask arrays, e.g., so you can pass one into a matplotlib function.</div></div></div></blockquote><div><br></div><div>Exactly.</div><div><br></div><div>And I have implemented __array__ in classes that are NOT duck arrays at all (an image class, for instance). But I also can see wanting to support both:</div><div><br></div><div>use me as a duck array</div><div>and </div><div>convert me into a proper numpy array.</div><div><br></div><div>OK -- looking again at the NEP, I see this suggested implementation:</div><div><br></div><div><font face="monospace"> def duckarray(array_like):<br> if hasattr(array_like, '__duckarray__'):<br> return array_like.__duckarray__()<br> return np.asarray(array_like)<br></font></div><div><br></div><div>So I see the point now, if a user wants a duck array -- they may not want to accidentally coerce this object to a real array (potentially expensive).</div><div><br></div><div>but in this case, asarray() will only get called (and thus __array__ will only get called), if __duckarray__ is not implemented. So the only reason to impliment __array__ and raise and Exception is so that users will get that exception is the specifically call asarray() -- why should they get that??</div><div><br></div><div>I'm working on a PR with suggestion for this.</div><div><br></div><div>-CHB</div></div><div><br></div>-- <br><div dir="ltr" class="gmail-m_6859853894815345340gmail-m_3195957051072141610gmail_signature"><br>Christopher Barker, Ph.D.<br>Oceanographer<br><br>Emergency Response Division<br>NOAA/NOS/OR&R (206) 526-6959 voice<br>7600 Sand Point Way NE (206) 526-6329 fax<br>Seattle, WA 98115 (206) 526-6317 main reception<br><br><a href="mailto:Chris.Barker@noaa.gov" target="_blank">Chris.Barker@noaa.gov</a></div></div>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail-m_6859853894815345340gmail_signature"><br>Christopher Barker, Ph.D.<br>Oceanographer<br><br>Emergency Response Division<br>NOAA/NOS/OR&R (206) 526-6959 voice<br>7600 Sand Point Way NE (206) 526-6329 fax<br>Seattle, WA 98115 (206) 526-6317 main reception<br><br><a href="mailto:Chris.Barker@noaa.gov" target="_blank">Chris.Barker@noaa.gov</a></div>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><br>Christopher Barker, Ph.D.<br>Oceanographer<br><br>Emergency Response Division<br>NOAA/NOS/OR&R (206) 526-6959 voice<br>7600 Sand Point Way NE (206) 526-6329 fax<br>Seattle, WA 98115 (206) 526-6317 main reception<br><br><a href="mailto:Chris.Barker@noaa.gov" target="_blank">Chris.Barker@noaa.gov</a></div>