问题
I have a little helper class:
class AnyOf(object):
def __init__(self, *args):
self.elements = args
def __eq__(self, other):
return other in self.elements
This lets me do sweet magic like:
>>> arr = np.array([1,2,3,4,5])
>>> arr == AnyOf(2,3)
np.array([False, True, True, False, False])
without having to use a list comprehension (as in np.array(x in (2,3) for x in arr
).
(I maintain a UI that lets (trusted) users type in arbitrary code, and a == AnyOf(1,2,3)
is a lot more palatable than a list comprehension to the non-technically savvy user.)
However!
This only works one way! For example, if I were to do AnyOf(2,3) == arr
then my AnyOf
class's __eq__
method never gets called: instead, the NumPy array's __eq__
method gets called, which internally (I would presume) calls the __eq__
method of all its elements.
This lead me to wonder: why does Python not allow a right-sided equivalent to __eq__
? (Roughly equivalent to methods like __radd__
, __rmul__
, et cetera.)
回答1:
An __req__
is not a good idea in the language, because if class Left
defines __eq__
and class Right
defines __req__
, then Python is obliged to make a consistent decision about who gets called first in Left() == Right()
. They can't both win.
However, the Python datamodel does allow a way for you to do what you want here. From both sides you can control this comparison, but you'll need to define AnyOf
correctly. If you want AnyOf
to control the __eq__ from the right hand side, you must define it to be a subclass of np.ndarray
.
if I were to do
AnyOf(2,3) == arr
then myAnyOf
class's__eq__
method never gets called
No, you have a fundamental misunderstanding here. The left hand side always gets first try at the equality comparison, unless the right hand side is a subclass of the type of the left hand side.
arr == AnyOf(2,3)
In the case above, your custom __eq__
is being called, because the numpy array calls it! So np.ndarray
wins, and it decides to check once per element. It literally could do anything else, including not calling your AnyOf.__eq__
at all.
AnyOf(2,3) == arr
In the case above, your class does get the first try at the comparison, and it fails because of the way you used in
(checking if an array is in a tuple).
回答2:
This is the documentation on the data model:
There are no swapped-argument versions of these methods (to be used when the left argument does not support the operation but the right argument does); rather,
__lt__()
and__gt__()
are each other’s reflection,__le__()
and__ge__()
are each other’s reflection, and__eq__()
and__ne__()
are their own reflection. If the operands are of different types, and right operand’s type is a direct or indirect subclass of the left operand’s type, the reflected method of the right operand has priority, otherwise the left operand’s method has priority. Virtual subclassing is not considered.
As stated in the comments above, what you want works, and __eq__
is essentially the sames as a potential __req__
: it is called on the right hand side of ==
if the object on the left hand side returns 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
As it comes, it even work with other, ordinary, objects:
In [10]: 5 == B()
B comparing
Out[10]: True
However, some objects may yield a TypeError on __eq__
instead of returning NotImplemented
or False
, and that makes this not reliable for all kinds of objects.
What happens in your case, is an incorrect use of the operator in
with arrays and tuples inside your own __eq__
method. (Thanks @wim to have spotted this in another answer here).
回答3:
The documentation about the __rxx__
methods like __radd__
states:
These functions are only called if the left operand does not support the corresponding operation and the operands are of different types.
While classes don't have __add__
or __sub__
methods per default, they do have __eq__
:
>>> class A(object):
... pass
>>> '__eq__' in dir(A)
True
This means __req__
would never be called unless you explicitly remove __eq__
from the other class.
You can solve your specific problem with np.in1d
:
>>> np.in1d(arr, [2, 3])
array([False, True, True, False, False], dtype=bool)
来源:https://stackoverflow.com/questions/47577395/why-doesnt-python-have-a-req-reflected-equality-method