> > On Nov 17, 4:35 am, John Machin <[EMAIL PROTECTED]> wrote: >> Worse: Consider z = ['A1', 'Z9']. It's highly likely that when x == >> 'A1', "x is_in z" is True -- because an unguaranteed implementation- >> dependent caper caches or "interns" some values, so that x and z[0] >> are the same object. Try explaining that to the novices!! >> > I am not a programmer so I feel odd commenting about language design > decisions. When my Prof. introduced python the first question that > popped into mind was that since "x=9; y=9; print x is y and x == y" > prints "True" is there a way to change the value of 9? He said that > was silly but after class showed me that statements "True = []" work > but suggested it was harmless and not quite a bug. > > So if I am permitted to think of integers as immutable objects with > predefined labels (i.e. the integers used in the text of the program > code) that cannot de or re referenced then what a similar treatment of > characters will look like seams to be an arbitary (a design) decition.
You are permitted to think as you will :-) However an integer object in general has no predefined label. It may have multiple names, or no name at all. a = 4567; b = a; assert b is a a = 2000; b = 1000 + 1000 # can assert b == a, can't assert b is a You are approaching this from the wrong end. Briefly: Everything about == works as expected. It is quite possible for a == b to be true but a is b to be false. This is a non-arbitrary design decision. One fact that I didn't tell you: Integers in range(-1, 101) are interned in the CPython implementation, similar to the string interning that you mentioned. For your wishes to come true, *every* value would have to be interned. This is impractical. > > In this vein it seams reasonable to expect 'a'[0] and 'ba'[1] to refer > to the same object. > If one follows the convention used with integers > (9 and 9 refer to the same object) then 'ab' and 'ab' would be the > same. An equally reasonable assumption would be that 'ab' and 'ab' are > two different sequences and so not equal (I do not see the problem > here). > > Actually this is what you said is left up to the implementation. '==' > seams to add a lot of power but I am not sure where or how (except as > a shortcut in the very special case of strings). Pardon the babble. Look at it this way: "==" (same value) is what one normally needs. The utility of "is" (same object) is much smaller. > > > On Nov 17, 4:35 am, John Machin <[EMAIL PROTECTED]> wrote: >> Do you have a use case for that? >> > I have a list of lists and want to see if another list is a member of > it. The content of the lists and the way they are related to each > other changes from program to program. I meant "What practical use do you have for two mutually recursive cursive lists?". -- http://mail.python.org/mailman/listinfo/python-list
