<div dir="ltr"><div class="markdown-here-wrapper" style="font-size:1em;font-family:Helvetica,arial,freesans,clean,sans-serif;color:rgb(34,34,34);background-color:rgb(255,255,255);border:none;line-height:1.2"><blockquote style="margin:1em 0px;border-left:4px solid rgb(221,221,221);padding:0px 1em;color:rgb(119,119,119);quotes:none">
<p style="margin:1em 0px">Subclasses such as MaskedArray and, yes, Quantity, are widely used, and if they cause problems perhaps that should be seen as a sign that ndarray subclassing should be made easier and clearer. </p>
</blockquote>
<p style="margin:1em 0px">Both maskedarray and quantity seem like something that would make more sense at the dtype level if our dtype system was easier to extend. It might be good to compile a list of subclassing applications, and split them into “this ought to be a dtype” and “this ought to be a different type of container”.</p>
<div title="MDH:Jmd0O8KgPHNwYW4gc3R5bGU9ImNvbG9yOiByZ2IoMzMsIDMzLCAzMyk7Ij5TdWJjbGFzc2VzIHN1
Y2ggYXMgTWFza2VkQXJyYXkgYW5kLCB5ZXMsIFF1YW50aXR5LCBhcmUgd2lkZWx5IHVzZWQsIGFu
ZCBpZiB0aGV5IGNhdXNlIHByb2JsZW1zIHBlcmhhcHMgdGhhdCBzaG91bGQgYmUgc2VlbiBhcyBh
IHNpZ24gdGhhdCBuZGFycmF5IHN1YmNsYXNzaW5nIHNob3VsZCBiZSBtYWRlIGVhc2llciBhbmQg
Y2xlYXJlci4mbmJzcDs8YnI+PGJyPkJvdGggbWFza2VkYXJyYXkgYW5kIHF1YW50aXR5IHNlZW0g
bGlrZSBzb21ldGhpbmcgdGhhdCB3b3VsZCBtYWtlIG1vcmUgc2Vuc2UgYXQgdGhlIGR0eXBlIGxl
dmVsIGlmIG91ciBkdHlwZSBzeXN0ZW0gd2FzIGVhc2llciB0byBleHRlbmQuIEl0IG1pZ2h0IGJl
IGdvb2QgdG8gY29tcGlsZSBhIGxpc3Qgb2Ygc3ViY2xhc3NpbmcgYXBwbGljYXRpb25zLCBhbmQg
c3BsaXQgdGhlbSBpbnRvICJ0aGlzIG91Z2h0IHRvIGJlIGEgZHR5cGUiIGFuZCAidGhpcyBvdWdo
dCB0byBiZSBhIGRpZmZlcmVudCB0eXBlIG9mIGNvbnRhaW5lciIuPC9zcGFuPg==" style="height:0;width:0;max-height:0;max-width:0;overflow:hidden;font-size:0em;padding:0;margin:0">​</div></div></div><br><div class="gmail_quote"><div dir="ltr">On Fri, 19 Oct 2018 at 18:24 Marten van Kerkwijk <<a href="mailto:m.h.vankerkwijk@gmail.com">m.h.vankerkwijk@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Hi All,<br></div><div><br></div><div>It seems there are two extreme possibilities for general functions:</div><div>1. Put `asarray` everywhere. The main benefit that I can see is that even if people put in list instead of arrays, one is guaranteed to have shape, dtype, etc. But it seems a bit like calling `int` on everything that might get used as an index, instead of letting the actual indexing do the proper thing and call `__index__`.<br></div><div>2. Do not coerce at all, but rather write code assuming something is an array already. This will often, but not always, just work for array mimics, with coercion done only where necessary (e.g., in lower-lying C code such as that of the ufuncs which has a smaller API surface and can be overridden more easily).</div><div><br></div><div>The current __array_function__ work may well provide us with a way to combine both, if we (over time) move the coercion inside `ndarray.__array_function__` so that the actual implementation *can* assume it deals with pure ndarray - then, when relevant, calling that implementation will be what subclasses/duck arrays can happily do (and it is up to them to ensure this works).</div><div><br></div><div>Of course, the above does not really answer what to do in the meantime. But perhaps it helps in thinking of what we are actually aiming for.</div><div><br></div><div>One last thing: could we please stop bashing subclasses? One can subclass essentially everything in python, often to great advantage. Subclasses such as MaskedArray and, yes, Quantity, are widely used, and if they cause problems perhaps that should be seen as a sign that ndarray subclassing should be made easier and clearer. <br></div><div><br></div><div>All the best,</div><div><br></div><div>Marten</div><div><div><br></div></div></div><br><div class="gmail_quote"><div dir="ltr">On Fri, Oct 19, 2018 at 7:02 PM Ralf Gommers <<a href="mailto:ralf.gommers@gmail.com" target="_blank">ralf.gommers@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Fri, Oct 19, 2018 at 10:28 PM Ralf Gommers <<a href="mailto:ralf.gommers@gmail.com" target="_blank">ralf.gommers@gmail.com</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"><br><br><div class="gmail_quote"><div dir="ltr">On Fri, Oct 19, 2018 at 4:15 PM Hameer Abbasi <<a href="mailto:einstein.edison@gmail.com" target="_blank">einstein.edison@gmail.com</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 style="font-family:Helvetica;color:rgb(0,0,0);font-size:13px"><div id="m_2159003868026931353m_6396869678531188226gmail-m_5627656941379967435m_256686967757922553CanaryBody"> <div> Hi!</div><div><br></div></div> <div id="m_2159003868026931353m_6396869678531188226gmail-m_5627656941379967435m_256686967757922553CanaryDropbox"> </div> <blockquote id="m_2159003868026931353m_6396869678531188226gmail-m_5627656941379967435m_256686967757922553CanaryBlockquote"> <div> <div>On Friday, Oct 19, 2018 at 6:09 PM, Stephan Hoyer <<a href="mailto:shoyer@gmail.com" target="_blank">shoyer@gmail.com</a>> wrote:<br></div> <div><div dir="ltr">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.</div><div dir="ltr"><br></div></div></div></blockquote>Agreed so far.<br></div></blockquote><div><br></div><div>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).<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 style="font-family:Helvetica;color:rgb(0,0,0);font-size:13px"><blockquote><div><div><div dir="ltr"><br></div><div dir="ltr">The preferred way to override NumPy functions going forward should be __array_function__.</div><div dir="ltr"><br></div></div></div></blockquote><br>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.</div></blockquote><div><br></div><div>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.<br></div><div> <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 style="font-family:Helvetica;color:rgb(0,0,0);font-size:13px"><div><br><blockquote><div><div><br><div class="gmail_quote"><div dir="ltr">On Fri, Oct 19, 2018 at 8:13 AM Marten van Kerkwijk <<a href="mailto:m.h.vankerkwijk@gmail.com" target="_blank">m.h.vankerkwijk@gmail.com</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><div>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.<br></div></div></div></blockquote></div></div></div></blockquote></div></div></blockquote><div>I don't quite understand this. Adding exceptions is not deprecation - we then may as well just rip np.matrix out straight away.</div><div><br></div><div>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.</div></div></div></blockquote><div><br></div><div>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 <a href="https://github.com/numpy/numpy/pull/11162" target="_blank">https://github.com/numpy/numpy/pull/11162</a> straight away.</div><div><br></div><div>Cheers,<br></div><div>Ralf</div><div><br></div></div></div></div>
_______________________________________________<br>
NumPy-Discussion mailing list<br>
<a href="mailto:NumPy-Discussion@python.org" target="_blank">NumPy-Discussion@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/numpy-discussion" rel="noreferrer" target="_blank">https://mail.python.org/mailman/listinfo/numpy-discussion</a><br>
</blockquote></div>
_______________________________________________<br>
NumPy-Discussion mailing list<br>
<a href="mailto:NumPy-Discussion@python.org" target="_blank">NumPy-Discussion@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/numpy-discussion" rel="noreferrer" target="_blank">https://mail.python.org/mailman/listinfo/numpy-discussion</a><br>
</blockquote></div>