Roy Smith wrote:
On May 12, 2011, at 11:30 AM, Eric Snow wrote:
That definitely makes it unclear.
I don't think it's unclear at all. It's very clear. Clearly wrong :-)
While it is wrong (it should have 'built-in' precede the word 'types'),
it is not wrong in the way you think -- a subclass *is* a type of its
superclass.
A little further down it says that you can customize comparison with
the __cmp__ special method.
>
I read that as saying that if you implement __eq__(), you must make sure
that it returns False if self and other have different types (and
likewise, __ne__() should return True for that case).
Your understanding is flawed. If your object does not know how to
compare itself to some other object, it should return NotImplemented --
at that point Python will follow the rules outlined in the docs. By
returning NotImplemented you are allowing the other object a chance to
perform the comparison -- after all, it might know how! :) If the
other object also returns NotImplemented then (drum-roll please) they
won't compare equal.
The same way that it says that obj1.__lt__(obj2) must return a consistent
> result for all types of obj1 and obj2.
Where do you see that? I couldn't find it.
The point of being able to write your own rich comparison methods is so
you can control what happens -- there is no "must" about it. This is
Python -- do what you want! :)
~Ethan~
PS
I have a broken sense of humor -- sometimes it works, sometimes it
doesn't. My apologies in advance if my attempt at humor was not funny.
--
http://mail.python.org/mailman/listinfo/python-list
