Home Original page

[Python-ideas] checking for identity before comparing built-in objects

Guido van Rossum guido at python.org
Mon Oct 8 18:29:42 CEST 2012 
On Sun, Oct 7, 2012 at 8:09 PM, Rob Cliffe <rob.cliffe at btinternet.com> wrote:
> I understand that the undefined result of a computation is not the same as
> the undefined result of another computation.
> (E.g. one might represent positive infinity, another might represent
> underflow or loss of accuracy.)
> But I can't help feeling (strongly) that the result of a computation should
> be equal to itself.
> In other words, after
>     x = float('nan')
>     y = float('nan')
> I would expect
>     x != y
> but
>     x == x

That's too bad. It sounds like this mailing list really wouldn't have
enough space in its margins to convince you otherwise. And yet you are
wrong.

> After all, how much sense does this make (I got this in a quick test with
> Python 2.7.3):
>>>> x=float('nan')
>>>> x is x
> True            # Well I guess you'd sorta expect this
>>>> x==x
> False           # You what?
>>>> D = {1:x, 2:x}
>>>> D[1]==D[2]
> False          # I see, both NANs - hmph!
>>>> [x]==[x]
> True            # Oh yeh, it doesn't always work that way then?
>
> Making equality non-reflexive feels utterly wrong to me, partly no doubt
> because of my mathematical background,

Do you have any background at all in *numerical* mathematics?

> partly because of the difficulty in
> implementing container objects and algorithms and God knows what else when
> you have to remember that some of the objects they may deal with may not be
> equal to themselves.  In particular the difference between my last two
> examples ( D[1]!=D[2] but [x]==[x] ) looks impossible to justify except by
> saying that for historical reasons the designers of lists and the designers
> of dictionaries made different - but entirely reasonable - assumptions about
> the equality relation, and (perhaps) whether identity implies equality (how
> do you explain to a Python learner that it doesn't (pathological code
> examples aside) ???).
> Couldn't each NAN when generated contain something that identified it
> uniquely, so that different NANs would always compare as not equal, but any
> given NAN would compare equal to itself?

It's not about equality. If you ask whether two NaNs are *unequal* the
answer is *also* False.

I admit that a tutorial section describing the behavior would be good.
But I am less than ever convinced that it's possible to explain the
*reason* for the behavior in a tutorial.

-- 
--Guido van Rossum (python.org/~guido)
More information about the Python-ideas mailing list