在语言中，__req__可能被认为比“有用”更令人困惑，考虑一下，如果类Left定义__eq__，类Right定义__req__，那么Python就必须做出一个“一致”的决定，决定在Left() == Right()中谁先被调用（我们大概希望结果是等价的，无论哪种方式），他们不可能都赢。
然而，Python数据模型允许你在这里做你想做的事情。比较可以从操作的任何一端控制，但是你需要以一种特殊的方式定义AnyOf。当比较的左边是一个np.ndarray示例时，为了从右边控制eq**，AnyOf应该是np.ndarray的子类。**
如果我执行AnyOf(2,3) == arr，那么我的AnyOf类的__eq__方法永远不会被调用
实际上，不，这里有一个明显的基本误解，左边的类型 * 总是 * 首先尝试处理相等比较，除非右边的类型是左边类型的子类。

arr == AnyOf(2,3)

在上面的比较中，你的定制__eq__ * 被调用了，因为numpy数组调用了它！所以np.ndarray胜出，它决定对每个元素检查一次，它可以做任何其他事情，包括根本不调用你的AnyOf.__eq__。

AnyOf(2,3) == arr

在上面显示的比较中，您的类确实获得了比较的第一次尝试，但由于in的使用方式-return other in self.elements正在检查数组是否在元组中，所以它失败了。

以下是有关数据模型的文档：
这些方法没有参数交换的版本（当左边的参数不支持操作而右边的参数支持时使用）;相反，__lt__()和__gt__()是彼此的反射，__le__()和__ge__()是彼此的反射，并且**__eq__()**和__ne__()是它们自己的反射。如果操作数是不同类型的，并且右操作数的类型是左操作数的类型的直接或间接子类，则右操作数的反射方法具有优先级。否则左操作数的方法优先，不考虑虚子类。
正如上面的注解所述，您所需要的是可行的，__eq__本质上与潜在的__req__相同：如果左手的对象返回NotImplemented，则在==的右侧调用该函数：

In [1]: class A:
   ...:     def __eq__(self, other):
   ...:         return NotImplemented
   ...:     

In [2]: class B:
   ...:     def __eq__(self, other): 
   ...:         print("B comparing")
   ...:         return True
   ...:     

In [3]: B() == A()
B comparing
Out[3]: True

In [4]: A() == B()
B comparing
Out[4]: True

In [5]: A() == A()
Out[5]: False

当它出现时，它甚至可以与其他普通对象一起工作：

In [10]: 5 == B()
B comparing
Out[10]: True

但是，某些对象可能会在__eq__上生成TypeError，而不是返回NotImplemented或False，这使得这对于所有类型的对象都不可靠。
在您的例子中，发生的是在您自己的__eq__方法中对数组和元组错误地使用了操作符in。（感谢@wim在这里的另一个答案中发现了这一点）。

关于__rxx__方法（如__radd__）的文档指出：
仅当左操作数不支持相应的运算并且操作数属于不同类型时，才调用这些函数。
虽然类默认情况下没有__add__或__sub__方法，但它们确实有__eq__：

>>> class A(object):
...     pass
>>> '__eq__' in dir(A)
True

这意味着__req__永远不会被调用，除非您显式地从其他类中删除__eq__或使__eq__返回NotImplemented。
您可以使用np.in1d解决您的特定问题：

>>> np.in1d(arr, [2, 3])
array([False,  True,  True, False, False], dtype=bool)