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

Oscar Benjamin oscar.j.benjamin at gmail.com
Tue Oct 9 02:32:39 CEST 2012

On 9 October 2012 01:11, Guido van Rossum <guido at python.org> wrote:
> On Mon, Oct 8, 2012 at 5:02 PM, Greg Ewing <greg.ewing at canterbury.ac.nz> wrote:
>> So the question that really needs to be answered, I think, is
>> not "Why is NaN == NaN false?", but "Why doesn't NaN == anything
>> raise an exception, when it would make so much more sense to
>> do so?"
> Because == raising an exception is really unpleasant. We had this in
> Python 2 for unicode/str comparisons and it was very awkward.
> Nobody arguing against the status quo seems to care at all about
> numerical algorithms though. I propose that you go find some numerical
> mathematicians and ask them.

The main purpose of quiet NaNs is to propagate through computation
ruining everything they touch. In a programming language like C that
lacks exceptions this is important as it allows you to avoid checking
all the time for invalid values, whilst still being able to know if
the end result of your computation was ever affected by an invalid
numerical operation. The reasons for NaNs to compare unequal are no
doubt related to this purpose.

It is of course arguable whether the same reasoning applies to a
language like Python that has a very good system of exceptions but I
agree with Guido that raising an exception on == would be unfortunate.
How many people would forget that they needed to catch those
exceptions? How awkward could your code be if you did remember to
catch all those exceptions? In an exception handling language it's
important to know that there are some operations that you can trust.


More information about the Python-ideas mailing list