[Numpy-discussion] NEP: Dispatch Mechanism for NumPy’s high level API (original) (raw)

Hameer Abbasi einstein.edison at gmail.com
Sun Jun 3 14:52:43 EDT 2018

• Previous message (by thread): [Numpy-discussion] NEP: Dispatch Mechanism for NumPy’s high level API
• Next message (by thread): [Numpy-discussion] NEP: Dispatch Mechanism for NumPy’s high level API
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

I also am not sure there is an actual problem: In the scheme as proposed, implementations could just coerce themselves to array and call the routine again. (Or, in the scheme I proposed, call the routine again but with coerce=True.)

Ah, I didn’t think of the first solution. coerce=True may not produce the desired solution in cases where some arguments can be coerced and some can’t.

However, such a design may still have some benefits. For example:

• array1.HANDLED_TYPES = [array1]
• array2.HANDLED_TYPES = [array1, array2]
• array1 is coercible.
• None of these is a sub/super class of the other or of ndarray
• When calling np.func(array1(), array2()), array1 would be coerced with your solution (because of the left-to-right rule and array1 choosing to coerce itself) but not with np.NotImplementedButCoercible.

I think that in the proposed scheme this is effectively what happens.

Not really, the current scheme is unclear on what happens if none of the arguments implement __array_function__ (or at least it doesn’t explicitly state it that I can see). -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20180603/4c2ce32f/attachment-0001.html>

• Previous message (by thread): [Numpy-discussion] NEP: Dispatch Mechanism for NumPy’s high level API
• Next message (by thread): [Numpy-discussion] NEP: Dispatch Mechanism for NumPy’s high level API
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

More information about the NumPy-Discussion mailing list