[Numpy-discussion] Adding to the non-dispatched implementation of NumPy methods

[Stefan van der Walt]

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

> On Mon, Apr 15, 2019 at 4:39 PM Stephan Hoyer <shoyer at gmail.com> wrote:
>>
>> On Mon, Apr 15, 2019 at 1:21 PM Nathaniel Smith <njs at 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 at python.org
> https://mail.python.org/mailman/listinfo/numpy-discussion