Implement hasattr(), str() and repr(). - #8442

Thanks for the review @guilhermeleobas. Two remarks:

1. Yes, len needs to defer to obj.__len__. I think that's it though for protocol based function support (ignoring operator.*)? Can you think of any others in the Numba code base at present?
2. Your comment makes me wonder if there ought to be a concept of "protected" overloads to warn users about overloading an implementation at an unusual level, i.e. warn on overloading len that overload obj.__len__ is the preferred behaviour, that sort of thing.

I searched for __ on https://docs.python.org/3/library/functions.html and these are the functions I found that has a corresponding dunder method:

• abs -> __abs__()
• bin(x) -> __index__(), when x is not an int
• callable -> __call__()
• complex -> __complex__() or __float__() or __index__()
• enumerate -> __next__()
• float -> __float__() or __index__()
• hex -> __index__()
• int -> __int__() or __index__() or __trunc__()
• iter -> Must support either the iterable or the sequence protocol
• next -> __next__()
• reversed -> __reversed__()
• round -> __round__() for python object

I searched for __ on https://docs.python.org/3/library/functions.html and these are the functions I found that has a corresponding dunder method:

Thanks @guilhermeleobas, from memory, I think that Numba has implementations for a reduced set of these, namely:

* `abs` -> `__abs__()`
* `complex` -> `__complex__()` or `__float__()` or `__index__()`
* `enumerate` -> `__next__()`
* `float` -> `__float__()` or `__index__()`
* `int` -> `__int__()` or `__index__()` or `__trunc__()`
* `iter` -> Must support either the iterable or the sequence protocol
* `next` -> `__next__()`
* `round` -> `__round__()` for python object

I'm not sure if it's possible to handle iter, enumerate and next very easily due to the stack based nature of their implementations, the rest, however, should be doable.

In the interests of making this feature available for Numba 0.57, what needs to be done to get this patch to a state where it's sufficiently useful to be able to merge it? Is it potentially "just" resolving these questions: #8442 (comment) ?

I don't think that it's going to be possible to handle quite a few of those dunder methods above trivially in this PR. For example abs uses concrete templates which makes it hard to translate to an overload, the constructors like float and int are entangled with the NumPy machinery and others like next are stack based, which makes them reliant on direct lowering (though could go via the overload inliner eventually).

Thanks for the review @sklam, comments should now be addressed.

1c5970d failed in Azure CI on the macos_py37_np118 build with:

======================================================================
FAIL: test_reflect_exception (numba.tests.test_sets.TestSetReflection)
When the function exits with an exception, sets should still be
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/runner/work/1/s/numba/tests/test_sets.py", line 813, in test_reflect_exception
    self.assertPreciseEqual(s, set([1, 2, 3, 42]))
  File "/Users/runner/miniconda3/envs/azure_ci/lib/python3.7/contextlib.py", line 119, in __exit__
    next(self.gen)
  File "/Users/runner/work/1/s/numba/tests/support.py", line 266, in assertRefCount
    % (old, new, obj))
AssertionError: Refcount changed from 4 to 6 for object: {1, 2, 3, 42}

This doesn't reproduce locally. Rerunning the CI job to see if it's transient.

This doesn't reproduce locally. Rerunning the CI job to see if it's transient.

It's not transient.

/AzurePipelines run

9ef54ce fixes the transient issue.

Need to do: #8442 (comment) Done in b819f01.