On Thu, Apr 28, 2011 at 1:48 PM, Terry Reedy
On 4/28/2011 12:55 PM, Guido van Rossum wrote:
*If* my proposal gets accepted, there will be a blanket rule that no matter how exotic an type's __eq__ is defined, self.__eq__(self) (i.e., __eq__ called with the same *object* argument) must return True if the type's __eq__ is to be considered well-behaved;
This, to me, is a statement of the obvious ;-), but it should be stated in the docs.
Do you also propose to make NaNs at least this well-behaved or leave them ill-behaved?
As I said, my proposal is to consider this a bug of the same severity as __hash__ and __eq__ disagreeing, and would require float and Decimal to be changed. The more conservative folks are in favor of not changing anything (except the abstract Sequence class), and solving things by documentation only. In that case the exotic current behavior of should not be considered a bug but merely unusual, and the behavior of collections (assuming an object is always equal to itself, never mind what its __eq__ says) documented as just that. There would not be any mention of well-behaved nor a judgment that NaN is not well-behaved. If my proposal is accepted, the definition of sequence comparison etc. would actually become simpler, since it should not have to mention the special-casing of object identity; instead it could mention the assumption of items being well-behaved. Again, the relationship between __eq__ and __hash__ would be the model here; and in fact a "well-behaved" type would have both properties (__eq__ returns true -> same __hash__, object identity -> __eq__ returns true). A type that is not well-behaved has a bug. I do not want to declare the behavior of NaN a bug.
and Python
containers may assume (for the purpose of optimizing their own comparison operations) that their elements have a well-behaved __eq__.
This almost states the status quo of the implementation, and the doc needs to be updated correspondingly. I do not think we should let object ill-behavior infect containers, so that they also become ill-behaved (not equal to themselves).
There are other kinds of bad behavior that will still affect containers. So we have no choice about containers containing ill-behaved objects being (potentially) ill-behaved. In some sense the primary issue at hand is whether "x == x returns False" indicates that x has a bug, or not. If it is a bug, the current float and Decimal types have that bug, and need to be fixed; and then the current behavior of containers is "merely' an optimization which may fail if there is a buggy item. The alternative is that we continue to say that it is not a bug, merely exotic, and that containers should test for identity before equality, not just as an optimization, but as the very essence of their semantics. The third option would be to say that the optimization is wrong. But nobody wants that, as it would require a container's __eq__ method to always compare all items before returning True, even when comparing a containing to *itself*. -- --Guido van Rossum (python.org/~guido)