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

[Guido van Rossum]

On Mon, Oct 8, 2012 at 5:32 PM, Oscar Benjamin
<oscar.j.benjamin at gmail.com> wrote:
> 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.

If we want to do *anything* I think we should first introduce a
floating point context similar to the Decimal context. Then we can
talk.

-- 
--Guido van Rossum (python.org/~guido)