Guido van Rossum schrieb:
>> > __eq__ methods should always return True or False. They should
>> > only raise an exception if there is some internal error within
>> > one of the objects being compared -- they should never raise
>> > an exception because the other object is of an unexpected type.
>>
>> That policy is currently difficult to implement, but reasonable
>> (difficult because it is quite some code to write).
>
> Why? Are you thinking of the standard library, or of an end user's
> __eq__ method? Returning False from your __eq__ if other's type is
> unexpected doesn't seem a lot of code. Or am I misunderstanding
> something?
It seemed like a lot of code to me: In the specific enum example,
I first wrote
def __eq__(self, other):
return self.EnumType is other.EnumType \
and self.__value==other.__value
So this was wrong, as it did not take into account 'other' being
something completely different, and I wrote
def __eq__(self, other):
return type(self) is type(other) \
and self.EnumType is other.EnumType \
and self.__value==other.__value
Having two additional continuation lines seems quite difficult to
me, yet a version that breaks the expression into multiple statements
is even longer
def __eq__(self, other):
if type(self) is not type(other):
return False
if self.EnumType is not other.EnumType:
return False
return self.__value==other.__value
Compare this to the current two-line __cmp__ implementation:
def __cmp__(self, other):
assert self.Enumtype is other.EnumType
return cmp(self.__value, other.__value)
This covers all comparisons just fine in two lines of method
body; to implement the __eq__ policy, you need another 6
lines. For consistency, you should also implement __ne__,
probably as
def __ne__(self, other):
return not self.__eq__(other)
I expect many people get this wrong, for example
http://pyref.infogami.com/__eq__
UserList.py
Also, there is confusion as to whether NotImplemented
should ever be returned in these. decimal.py believes
it does (for different types), sets.py believes it
doesn't.
Regards,
Martin
_______________________________________________
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
