Thanks, would you be happy to add a test as well? It will need to be an object which raises an error when you call __bool__ and returns self for __eq__ probably.

Glad to add tests. I'm new here and did not quite understand when you say

raises an error when you call __bool__

This is the implementation of a python class with the specific behaviour, such as:

class MyNA:
    def __bool__(self):
        raise ValueError("MyNA cannot be interpreted as a boolean value.")

Since the code will also call MyNA() == MyNA() here, you also have to implement __eq__ check the special dunder methods when creating a python class.

Guys, I can't see a workaround, it's working in the shell but failing in the test script:

class CustomNA:
	def __bool__(self):
		raise TypeError("CustomNA cannot be interpreted as a boolean value.")

	def __eq__(self, other):
		return self
CustomNA() in np.array(["a"], dtype=object)

DeprecationWarning: elementwise comparison failed; this will raise an error in the future.

In shell:

>>> CustomNA() not in np.array(["a"], dtype=object)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<stdin>", line 5, in __bool__
TypeError: CustomNA cannot be interpreted as a boolean value.

Can you please help me. Apologies if it's a very basic doubt.

No, that is not basic at all... The whole issue is far more complicated than it appears, and the DeprecationWarning (which is raised as an error in the test, you will see identical results with import warnings; warnings.simplefilter("error")) makes things tricky.

The "correct" test could be hacked by adding __array_priority__ = 1 (which also shows how badly broken __contains__ is in yet another way...

Maybe Eric anticipated this. I am OK with just putting it in without a test also, it gets complicated to cover the exact code path you are hitting... But you can add it referencing this issue with gh-15553 in a comment so that there is at least some fighting chance of understanding what that test does/did...

Oh I see, I guess we can add that UT after fixing the main issue.

OK, I will just merge this for now. If anyone feels we should add the test with __array_priority__ just comment and I will do it, but it does feel a bit complicated.

The test failures are unrelated due to some gfortran issue.

Thanks for the merge @seberg, I'll try it myself and ask here if I'm stuck.