[Numpy-discussion] Revised NEP-18, array_function protocol (original) (raw)
Stephan Hoyer shoyer at gmail.com
Thu Jun 28 14:04:19 EDT 2018
- Previous message (by thread): [Numpy-discussion] Revised NEP-18, __array_function__ protocol
- Next message (by thread): [Numpy-discussion] Revised NEP-18, __array_function__ protocol
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On Wed, Jun 27, 2018 at 12:50 PM Stephan Hoyer <shoyer at gmail.com> wrote:
One concern this does raise is how to handle methods like those on RandomState, even though methods like randomlike() don't currently exist. Distribution objects from scipy.stats could have similar use cases.
So perhaps it's worth "future proofing" the interface by passing
obj
andmethod
to arrayfunction rather than onlyfunc
. It is slower to call a func via func.call than func, but only very marginally (~100 ns in my tests).
I did a little more digging, and turned up the self and func attributes of bound methods: https://stackoverflow.com/questions/4679592/how-to-find-instance-of-a-bound-method-in-python
So we might need another decorator function, but it seems that the current interface would actually suffice just fine for overriding methods. I'll update the NEP with some examples. It will look something like:
def array_function(self, func, types, args, kwargs): ... if isinstance(func, types.MethodType): object = func.self unbound_func = func.func ...
Given that functions are the most common case, I think it's best to keep
with func
as the main interface, but it's good to know that this does not
preclude overriding methods.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20180628/c44a436f/attachment.html>
- Previous message (by thread): [Numpy-discussion] Revised NEP-18, __array_function__ protocol
- Next message (by thread): [Numpy-discussion] Revised NEP-18, __array_function__ protocol
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]