On 01/07/13 22:15, Oscar Benjamin wrote:
On 1 July 2013 12:01, Dave Angel <da...@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
_______________________________________________
Tutor maillist - Tutor@python.org
To unsubscribe or change subscription options:
http://mail.python.org/mailman/listinfo/tutor
