[Python-Dev] PyObject_RichCompareBool identity shortcut

[Guido van Rossum]

On Thu, Apr 28, 2011 at 1:48 PM, Terry Reedy <tjreedy at udel.edu> wrote:
> 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)