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).
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion
