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 ([EMAIL PROTECTED]) ---------------------------------------------------------------------- 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 _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
