[Python-Dev] PyObject_RichCompareBool identity shortcut

Terry Reedy tjreedy at udel.edu
Wed Apr 27 21:51:15 CEST 2011


On 4/27/2011 11:31 AM, Nick Coghlan wrote:

> Currently, Python tries to split the difference: "==" and "!=" follow
> IEEE754 for NaN, but most other operations involving builtin types
> rely on the assumption that equality is always reflexive (and IEEE754
> be damned).
>
> What that means is that "correct" implementations of methods like
> __contains__, __eq__, __ne__, index() and count() on containers should
> be using "x is y or x == y" to enforce reflexivity, but most such code
> does not (e.g. our own collections.abc.Sequence implementation gets
> those of these that it implements wrong, and hence Sequence based
> containers will handle NaN in a way that differs from the builtin
> containers)
>
> And none of that is actually documented anywhere (other than a
> behavioural note in the 3.x documentation for
> PyObject_RichCompareBool), so it's currently just an implementation
> detail of CPython that most of the builtin containers behave that way
> in practice.

Which is why I proposed a Glossary entry in another post.

> Given the status quo, what would seem to be the path of least resistance is to:
> - articulate in the language specification which container special
> methods are expected to enforce reflexivity of equality (even for
> non-reflexive types)
> - articulate in the library specification which ordinary container
> methods enforce reflexivity of equality
> - fix any standard library containers that don't enforce reflexivity
> to do so where appropriate (e.g. collections.abc.Sequence)

+1 to making my proposed text consistenly true if not now ;-).

> Backing away from having float and decimal.Decimal respect the IEEE754
> notion of NaN inequality at this late stage of the game seems like one
> for the "too hard" basket.

Robert Kern confirmed my suspicion about this relative to numpy.

 > It also wouldn't achieve much, since we
> want the builtin containers to preserve their invariants even for 3rd
> party types with a non-reflexive notion of equality.

Good point.

-- 
Terry Jan Reedy



More information about the Python-Dev mailing list