<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
Hey all.<br>
Is there any update on this? Is there any input we can provide as
users?<br>
I'm not entirely sure where you are in the decision making process
right now :)<br>
<br>
Cheers,<br>
Andy<br>
<br>
<div class="moz-cite-prefix">On 3/3/20 6:34 PM, Sebastian Berg
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:e66ee15c3e1674d8c877594ab8e90aa1f7c403ef.camel@sipsolutions.net">
<pre class="moz-quote-pre" wrap="">On Fri, 2020-02-28 at 11:28 -0500, Allan Haldane wrote:
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">On 2/23/20 6:59 PM, Ralf Gommers wrote:
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">One of the main rationales for the whole NEP, and the argument in
multiple places
(
<a class="moz-txt-link-freetext" href="https://numpy.org/neps/nep-0037-array-module.html#opt-in-vs-opt-out-for-users">https://numpy.org/neps/nep-0037-array-module.html#opt-in-vs-opt-out-for-users</a>
)
is that it's now opt-in while __array_function__ was opt-out. This
isn't
really true - the problem is simply *moved*, from the duck array
libraries to the array-consuming libraries. The end user will still
see
the backwards incompatible change, with no way to turn it off. It
will
be easier with __array_module__ to warn users, but this should be
expanded on in the NEP.
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
Might it be possible to flip this NEP back to opt-out while keeping
the
nice simplifications and configurabile array-creation routines,
relative
to __array_function__?
That is, what if we define two modules, "numpy" and "numpy_strict".
"numpy_strict" would raise an exception on duck-arrays defining
__array_module__ (as numpy currently does). "numpy" would be a
wrapper
around "numpy_strict" that decorates all numpy methods with a call to
"get_array_module(inputs).func(inputs)".
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
This would be possible, but I think we strongly leaned against the
idea. Basically, if you have to opt-out, from a library perspective
there may be `np.asarray` calls, which for example later call into C
and expect arrays.
So, I have large doubts that an opt-out solution works easily for
library authors. Array function is opt-out, but effectively most clean
library code already opted out...
We had previously discussed the opposite, of having a namespace of
implicit dispatching based on get_array_module, but if we keep array
function around, I am not sure there is much reason for it.
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">
Then end-user code that did "import numpy as np" would accept
ducktypes
by default, while library developers who want to signal they don't
support ducktypes can opt-out by doing "import numpy_strict as np".
Issues with `np.as_array` seem mitigated compared to
__array_function__
since that method would now be ducktype-aware.
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
My tendency is that if we want to go there, we would need to push ahead
with the `np.duckarray()` idea instead.
To be clear: I currently very much prefer the get_array_module() idea.
It just seems much cleaner for library authors, and they are the
primary issue at the moment in my opinion.
- Sebastian
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">-Allan
_______________________________________________
NumPy-Discussion mailing list
<a class="moz-txt-link-abbreviated" href="mailto:NumPy-Discussion@python.org">NumPy-Discussion@python.org</a>
<a class="moz-txt-link-freetext" href="https://mail.python.org/mailman/listinfo/numpy-discussion">https://mail.python.org/mailman/listinfo/numpy-discussion</a>
</pre>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
NumPy-Discussion mailing list
<a class="moz-txt-link-abbreviated" href="mailto:NumPy-Discussion@python.org">NumPy-Discussion@python.org</a>
<a class="moz-txt-link-freetext" href="https://mail.python.org/mailman/listinfo/numpy-discussion">https://mail.python.org/mailman/listinfo/numpy-discussion</a>
</pre>
</blockquote>
</blockquote>
<br>
</body>
</html>