newbie Q: sequence membership

[John Machin]

> 
> On Nov 17, 4:35 am, John Machin <sjmac... at lexicon.net> 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 <sjmac... at lexicon.net> 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?".