[Python-Dev] PyObject_RichCompareBool identity shortcut (original) (raw)

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 PyObjectRichCompareBool), 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