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 <njs@pobox.com> wrote:

On Mon, Apr 15, 2019 at 4:39 PM Stephan Hoyer <shoyer@gmail.com> wrote:

On Mon, Apr 15, 2019 at 1:21 PM Nathaniel Smith <njs@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