(original) (raw)
Should there be discussion of typing (pep-484) or abstract base classes in this nep? Are there any requirements on the result returned by \_\_array\_function\_\_?
On Mon, Jun 4, 2018, 2:20 AM Stephan Hoyer <shoyer@gmail.com> wrote:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_On Sun, Jun 3, 2018 at 9:54 PM Hameer Abbasi <einstein.edison@gmail.com> wrote:Mixed return values of NotImplementedButCoercible and NotImplemented would still result in TypeError, and there would be no second chances for overloads.I would like to differ with you here: It can be quite useful to have second chances for overloads. Think \`\`np.func(list, custom\_array))\`\`: If second rounds did not exist, custom\_array would need to have a list of coercible types (which is not nice IMO).Even if we did this, we would still want to preserve the equivalence between:1\. Returning NotImplementedButCoercible from \_\_array\_ufunc\_\_ or \_\_array\_function\_\_, and2\. Not implementing \_\_array\_ufunc\_\_ or \_\_array\_function\_\_ at all.Changing \_\_array\_ufunc\_\_ to do multiple rounds of checks could indeed be useful in some cases, and you're right that it would not change existing behavior (in these cases we currently raise TypeError). But I'd rather leave that for a separate discussion, because it's orthogonal to our proposal here for \_\_array\_function\_\_.(Personally, I don't think it would be worth the additional complexity.)
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion