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

Ethan Furman ethan at stoneleaf.us
Thu Apr 28 03:11:15 CEST 2011

Mark Dickinson wrote:

On Wed, Apr 27, 2011 at 10:37 AM, Hrvoje Niksic <hrvoje.niksic at avl.com> wrote:

The other day I was surprised to learn this:

nan = float('nan') nan == nan False [nan] == [nan] True # also True in tuples, dicts, etc. That one surprises me a bit too: I knew we were using identity-then-equality checks for containment (nan in [nan]), but I hadn't realised identity-then-equality was also used for the item-by-item comparisons when comparing two lists. It's defensible, though: [nan] == [nan] should presumably produce the same result as {nan} == {nan}, and the latter is a test that's arguably based on containment (for sets s and t, s == t if each element of s is in t, and vice versa). I don't think any of this should change. It seems to me that we've currently got something approaching the best approximation to consistency and sanity achievable, given the fundamental incompatibility of (1) nan breaking reflexivity of equality and (2) containment being based on equality. That incompatibility is bound to create inconsistencies somewhere along the line. Declaring that 'nan == nan' should be True seems attractive in theory, but I agree that it doesn't really seem like a realistic option in terms of backwards compatibility and compatibility with other mainstream languages.

Totally out of my depth, but what if the a NaN object was allowed to compare equal to itself, but different NaN objects still compared unequal? If NaN was a singleton then the current behavior makes more sense, but since we get a new NaN with each instance creation is there really a good reason why the same NaN can't be equal to itself?

Ethan

More information about the Python-Dev mailing list