I thought this was simply a slot to store the NumPy version of the
dispatched method, so that you could see easily call through to it and
extend it.
Stephan, was there a deeper intent here that I missed?
Best regards,
Stéfan
On April 15, 2019 20:32:35 Nathaniel Smith <n...@pobox.com> wrote:
On Mon, Apr 15, 2019 at 4:39 PM Stephan Hoyer <sho...@gmail.com> wrote:
On Mon, Apr 15, 2019 at 1:21 PM Nathaniel Smith <n...@pobox.com> wrote:
What's the difference between
np.concatenate.__numpy_implementation__(...)
and
np.ndarray.__array_function__(np.concatenate, ...)
?
I can answer this technically, though this doesn't seem to be quite what
you're looking for:
- The former always succeed at dispatch, because it coerces all arguments
to NumPy arrays.
- The second will either return NotImplemented (if a non-NumPy arrays
implements __array_function__), or give the same result as former.
More generally, I guess I'm not quite clear on how to think about what the
"no dispatch" version does, because obviously it doesn't make sense to have
*no* dispatch. Instead it's something like "the legacy hard-coded dispatch"?
__numpy_implementation__ means you skip __array_function__ dispath and call
the original NumPy function. In practice, this means you get legacy
hard-coded dispatch behavior in most cases, e.g., the result will always be
in the form of NumPy array(s).
It doesn't mean that the implementation always coerces all arguments to
NumPy arrays. For example, np.result_type() will pull out of .dtype
attributes off of its arguments, even without necessarily coercing its
arguments to NumPy arrays. This strange version of "the implementation for
NumPy arrays" turns out to be something that several libraries that want to
implement __array_function__ want to be able to continue to use on their
own array objects (namely, JAX and CuPy).
Microsoft's "open standard" [1] document format, OOXML, famously
contains tags like "autoSpaceLikeWord95" and
"useWord97LineBreakRules". If you want to correctly interpret a Word
document, you have to know what these mean. (Unfortunately, the
standard doesn't say.)
Mostly I would like the definition for numpy 1.17's semantics to be
internally coherent and self-contained. If the documentation for
__numpy_implementation__ is just "it does whatever numpy 1.14 did",
then that seems not so great. Is there any way to define
__numpy_implementation__'s semantics without incorporating previous
versions of numpy by reference?
-n
[1] https://en.wikipedia.org/wiki/Standardization_of_Office_Open_XML
--
Nathaniel J. Smith -- https://vorpus.org
_______________________________________________
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion
_______________________________________________
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion
