On 28/04/2011 18:26, Steven D'Aprano wrote:
Rob Cliffe wrote:
To me the idea of non-reflexive equality (an object not being equal to itself) is abhorrent. Nothing is more likely to put off new Python users if they happen to run into it.
I believe that's a gross exaggeration. In any case, that's just your opinion, and Python is hardly the only language that supports (at least partially) NANs.
Besides, floats have all sorts of unintuitive properties that go against properties of real numbers, and new users manage to cope.
With floats, even ignoring NANs, you can't assume:
a*(b+c) == a*b + a*c a+b+c = c+b+a 1.0/x*x = 1 x+y-x = y x+1 > x
or many other properties of real numbers. In real code, the lack of reflexivity for NANs is just not that important. You can program for *years* without once accidentally stumbling over one, whereas you can't do the simplest floating point calculation without stubbing your toes on things like this:
1.0/10 0.10000000000000001
Of course, these are inevitable consequences of floating-point representation. Inevitable in just about *any* language.
The fact is, NANs are useful. Less useful in Python, which goes out of the way to avoid generating them (a pity, in my opinion), but still useful.
I am not arguing against the use of NANs. Or even against different NANs not being equal to each other. What I was arguing about was the behaviour of Python objects that represent NANs, specifically in allowing x == x to be False, something which is *not* inevitable but a choice of language design or usage. Rob Cliffe