Easy to obtain the weird behavior in the summary (in 2.5rc1 and earlier):

>>> inf=1e9999
>>> x = y = inf/inf
>>> x!=y and [x]==[y]
True

I propose to fix it by ensuring that lists (and tuples etc) compare their 
items with exactly the same logic as the == and != operators use.


Alex (aleaxit@gmail.com)

Logged In: YES 
user_id=1581732

This appears to be a special oddity of NaN, which is a
member of the set of "Things That Do Not Equal Themselves".

1.  Are there any more members of this set?
2.  Does this mean that any complex data type containing an
integer is no a member of this set?
3.  Is it odd that, say, a user's StatisticsArray will not
equal itself if some statistic in the array is Nan?

Logged In: YES 
user_id=1581732

FYI: while not directly related, NaN comparisons keep making
trouble.  Per bug 1514428, python makes the mistake that inf
> Nan should return false, just like Nan < inf.

Logged In: YES 
user_id=178886

This is a consequence of the way list equality is
implemented. Counterexample:

>>> inf=1e9999
>>> x=inf/inf
>>> y=inf/inf
>>> x!=y and [x] == [y]
False

i.e. [x] == [y] iff x is y

strings are interned in python (so 'a' is chr(97) returns
True), and ints (so 1+1 is 1+1 returns True) but not floats
(so inf/inf is inf/inf returns False). 

Interning floats (or at least "special" numbers, such as nan
or inf) could make sense, but I guess this is a RFE, and not
a bug, and a different one.

Logged In: YES 
user_id=178886

comparing tuples by == on elements, instead of "is", would
break tuple inmutability and make them unsuitable for keys,
BTW. Doing the same with lists would make them behave
different to tuples.

Liskov and Guttag (Addison Wesley, 2001) book has and
interesting discussion on equality in collections, and how
java's model has problems (as basically any model with
mutable objects that hash on content instead of identity).
Python has been doing it right for a lot of time.

Logged In: YES 
user_id=178886

sorry, forget my last comment, as floats are immutable.

Logged In: YES 
user_id=80475

IMO, this should not be changed.  Through-out Python (not
just for lists and tuples), internal routines assume that
identity implies equality.  All your example shows is that
the oddball NaN is in-fact odd.  IMO, the result weird, but
correct.  The x!=y result is correct because that is a
property of NaNs and the [x]==[y] result is correct because
the two lists have identical content.  You would get the
expected result when the content is not identical:

>>> inf=1e9999
>>> x = inf/inf
>>> y = inf/inf
>>> x != y
True
>>> [x] == [y]

I do not want the rest of Python mucked-up just because NaNs
are designed to not follow the most basic definitions of
equality (i.e. a relation is an equality relative if and
only if it is reflexsive, symmetric, and transitive). 
Closing as not-a-bug.