[Numpy-discussion] NEP: Dispatch Mechanism for NumPy’s high level API (original) (raw)
Stephan Hoyer shoyer at gmail.com
Mon Jun 4 02:19:51 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 ]
On Sun, Jun 3, 2018 at 9:54 PM Hameer Abbasi <einstein.edison at 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, customarray))
: If second rounds did not exist, customarray 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:
- Returning NotImplementedButCoercible from array_ufunc or array_function, and
- 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.) -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20180603/f1e34a66/attachment.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 ]