[Python-Dev] PyObject_RichCompareBool identity shortcut

Nick Coghlan ncoghlan at gmail.com
Thu Apr 28 12:27:21 CEST 2011


On Thu, Apr 28, 2011 at 7:10 PM, Greg Ewing <greg.ewing at canterbury.ac.nz> wrote:
> Nick Coghlan wrote:
>
>> Because this assertion is an assertion about the behaviour of
>> comparisons that violates IEEE754, while the assertions I list are all
>> assertions about the behaviour of containers that can be made true
>> *regardless* of IEEE754 by checking identity explicitly.
>
> Aren't you making something of a circular argument here?
> You're saying that non-reflexive comparisons are okay because
> they don't interfere with certain critical invariants. But
> you're defining those invariants as the ones that don't
> happen to conflict with non-reflexive comparisons!

No, I'm taking the existence of non-reflexive comparisons as a given
(despite agreeing with Meyer from a theoretical standpoint) because:
1. IEEE754 works that way
2. Even if float() is changed to not work that way, 3rd party types
may still do so
3. Supporting rich comparisons makes it impossible for Python to
enforce reflexivity at the language level (even if we wanted to)

However, as I detailed in my reply to Antoine, the critical container
invariants I cite *don't include* direct object-object comparisons.
Instead, they merely describe how objects relate to containers, and
how containers relate to each other, using only the two basic rules
that objects retrieved from a container should be in that container
and that two sets are equivalent if they are each a subset of the
other.

The question then becomes, how do we reconcile the container
invariants with the existence of non-reflexive definitions of equality
at the type level, and the answer is to officially adopt the approach
already used in the standard container types: enforce reflexive
equality at the container level, so that it doesn't matter that some
types provide a non-reflexive version.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia


More information about the Python-Dev mailing list