[ python-Bugs-1544762 ] x!=y and [x]==[y] (!)

SourceForge.net noreply at sourceforge.net
Thu Aug 24 22:13:33 CEST 2006


Bugs item #1544762, was opened at 2006-08-22 19:51
Message generated for change (Comment added) made by sgala
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1544762&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Alex Martelli (aleax)
Assigned to: Nobody/Anonymous (nobody)
Summary: x!=y and [x]==[y] (!)

Initial Comment:
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 at gmail.com)



----------------------------------------------------------------------

Comment By: Santiago Gala (sgala)
Date: 2006-08-24 22:13

Message:
Logged In: YES 
user_id=178886

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

----------------------------------------------------------------------

Comment By: Santiago Gala (sgala)
Date: 2006-08-24 13:32

Message:
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.

----------------------------------------------------------------------

Comment By: Santiago Gala (sgala)
Date: 2006-08-24 13:26

Message:
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.

----------------------------------------------------------------------

Comment By: CharlesMerriam (charlesmerriam)
Date: 2006-08-23 10:46

Message:
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.



----------------------------------------------------------------------

Comment By: CharlesMerriam (charlesmerriam)
Date: 2006-08-23 00:49

Message:
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?


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1544762&group_id=5470


More information about the Python-bugs-list mailing list