Jitclass: support for __call__ etc

[oyamad]

Despite #1571 (comment), would it be possible for jitclass to support special methods such as

1. __call__
2. __getitem__, __setitem__
3. __repr__, __str__
4. __iter__

and others?

__call__ would be especially useful since it will allow the instance to look like a jitted function that can be passed to another jitted function as an argument. See also https://groups.google.com/a/continuum.io/forum/#!topic/numba-users/YE12tE2dIwY.

[datnamer]

Also multiple inheritance would be great. @sklam that probably deserves its own issue?

[moble]

@datnamer Multiple inheritance seems to work, at least from my simple first test. The only wrinkle is that I calling the super __init__ functions is a bit tricky, even for single inheritance (see #1694), but it seems to work. Is there a different problem that simple tests don't turn up?

[moble]

I would also add the operators __add__, __radd__, __mul__, etc.

[datnamer]

@moble ok thanks.

I was also thinking of ways for easy code reuse and lightweight abstractions- how about abstract base classes and or user defined protocols/magic methods? (similar to traits).

[j-towns]

I want to re-iterate that overloading of math operators like __add__, __mul__ etc is essential for Autograd to be compatible with Numba (which would be awesome).

How difficult would this be to implement? I'm happy to help if I can.

[sklam]

It gets really tricky to match the exact python semantic due to the __radd__ and reflection.

[AriKatz]

Does that mean JIT class support will stay as is? If not, what are the long term plans?

[sklam]

I have plans to expand the JIT class support. Few months ago, I was working on various jitclass features but I was slowed down by many tricky details. Some of these details, like the operating overloading, can be implemented but with great cost in code complexity. I think it is partially due to the technical debts in the internals of numba. So, I am taking a pause in pushing new features for jitclasses and trying to clean things up a bit.

[moble]

Is this closed by #1851, as suggested by one of the improvements listed in the release notes for version 0.26.0?

[moble]

I guess not, as my tests all fail. #1865 implies that special cases are needed, and that was closed in favor of (the still-open) #2187.

[aldanor]

Wondering if there's any plans on reviving this?

There's a few tricky magic methods, but would be very nice to at least have the 'easy' ones like __str__ / __repr__.

[andreapiso]

Another nice one to have would be len. Great to see getitem and setitem work tho!

[justinblaber]

__repr__ would be very nice...

[alexpyattaev]

__iadd__ and __imul__ at the very least should be fairly straightforward as they do not need any memory manipulation whatsoever...

[alexpyattaev]

One other super-annoying thing is copy and deepcopy. Since jitclasses are nearly always leaf nodes in deepcopy, would it not make it possible to define copy and deepcopy methods to make it possible to deepcopy lists with numba objects in them?

[luk-f-a]

does #5877 implement __call__? I can't find it in the documentation (https://github.com/numba/numba/pull/5877/files#diff-6880417d39388a0df2223969338766f4482ef800575fec37101fcb0db6b55725)

[gmarkall]

Whoops, it does not. I'll reopen this to keep track of that.