[Tutor] Test Question

[Steven D'Aprano]

On 01/07/13 22:15, Oscar Benjamin wrote:
> On 1 July 2013 12:01, Dave Angel <davea at davea.name> wrote:
>> Third if my_object is something that doesn't equal anything else, such as a
>> floating point NAN.  Two NANs are not equal, and a NAN is not even equal to
>> itself.
>
> Many builtin collection types do an identity 'is' check before an
> equality '==' check so nan behaviour depends on whether it is the
> exact same nan:
>
>>>> float('nan') in [1, 2, 3, float('nan')]
> False
>>>> nan = float('nan')
>>>> nan in [1, 2, 3, nan]
> True
>
> I don't know to what extent that is a deliberate feature or an
> optimisation that wasn't fully considered but it at least maintains
> the following invariant:


It's an optimization, but one which by declaration of the BDFL stands. It simply isn't worth slowing down list processing for something as uncommon as NANs. Lists are general purpose containers, and shouldn't be expected to understand every little quirk of every weird value.

I am a strong supporter of the IEEE 754 behaviour of NANs, namely that if x is a NAN, x == x returns False. There are good reasons for this, *in the context of numerical computing*. Nevertheless, I support Guido's ruling on this. Lists are not part of IEEE 754, neither is object identity, and if somebody wants a list that is NAN-aware, they can make one:

# Untested.
class MyList(list):
     def __contains__(self, value):
         if math.isnan(value): return False
         return super().__contains__(value)



-- 
Steven