Mahesh wrote:
> I understand that what makes perfect sense to me might not make perfect
> sense to you but it seems a sane default. When you compare two objects,
> what is that comparision based on? In the explicit is better than
> implicit world, Python can only assume that you *really* do want to
> compare objects unless you tell it otherwise. The only way it knows how
> to compare two objects is to compare object identities.
This isn't the issue here. I agree that object identity comparison is
a good default equality test. The issue is whether this default should
be thought of as
# your approach (and the current implementation)
def __eq__(self, other):
return self is other
def __ne__(self, other):
return self is not other
or
# my approach
def __eq__(self, other):
return self is other
def __ne__(self, other):
return not (self == other)
My approach simplifies the implementation (i.e., requires one fewer
method to be overridden) of classes for which (x != y) == not (x == y).
This is a very common case.
Your approach simplifies the implementation of classes for which
equality tests are based on data but inequality tests are based on
identity (or vice-versa). I can't think of a single situation in which
this is useful.
--
http://mail.python.org/mailman/listinfo/python-list
