Bugs item #1544762, was opened at 2006-08-22 12:51 Message generated for change (Comment added) made by rhettinger 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: Invalid 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: Raymond Hettinger (rhettinger) Date: 2006-08-28 08:10 Message: 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. ---------------------------------------------------------------------- Comment By: Santiago Gala (sgala) Date: 2006-08-24 15: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 06: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 06: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 03: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-22 17: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
