[Python-Dev] == on object tests identity in 3.x (original) (raw)

Stephen J. Turnbull stephen at xemacs.org
Wed Jul 9 06:21:11 CEST 2014

Steven D'Aprano writes:

I don't think so. Floating point == represents numeric equality,

There is no such thing as floating point == in Python. You can apply == to two floating point numbers, but == (at the language level) handles any two numbers, as well as pairs of things that aren't numbers in the Python language. So it's a design decision to include NaNs at all, and another design decision to follow IEEE in giving them behavior that violates the definition of equivalence relation for ==.

In an early post, you suggested that NANs don't have a value, or that they have a value which is not a value. I don't think that's a good way to look at it. I think the obvious way to think of it is that NAN's value is Not A Number, exactly like it says on the box. Now, if something is not a number, obviously you cannot compare it numerically:

And if Python can't do something you ask it to do, it raises an exception. Why should this be different? Obviously, it's question of expedience.

I'm not sure what you're referring to here. Is it that containers such as lists and dicts are permitted to optimize equality tests with identity tests for speed?

No, when I say I'm fuzzy I'm referring to the fact that although I understand the logical rationale for IEEE 754 NaN behavior, I don't really understand the ins and outs well enough to judge for myself whether it's a good idea for Python to follow that model and turn == into something that is not an equivalence relation.

I'm not going to argue for a change, I just want to know where I stand.

Basically, and I realise that many people disagree with their decision (notably Bertrand Meyer of Eiffel fame, and our own Mark Dickenson),

Indeed. So "it's the standard" does not mean there is a consensus of experts. I'm willing to delegate to a consensus of expert opinion, but not when some prominent local expert(s) disagree -- then I'd like to understand well enough to come to my own conclusions.

More information about the Python-Dev mailing list