A question on modification of a list via a function invocation

[Chris Angelico]

On Wed, Sep 6, 2017 at 10:44 PM, Rustom Mody <rustompmody at gmail.com> wrote:
> On Wednesday, September 6, 2017 at 5:48:48 PM UTC+5:30, Chris Angelico wrote:
>> On Wed, Sep 6, 2017 at 10:11 PM, Rustom Mody  wrote:
>> >>>> a = (1,2)
>> >>>> b = (1,2)
>> >>>> a is b
>> > False
>> >>>> x = 1
>> >>>> y = 1
>> >>>> x is y
>> > True
>> >
>> > a seems to be as 'same' to b as x is to y
>> > Python seems to think otherwise
>> >
>> > Evidently your ‘same’ is not the same as mine??
>>
>> *facepalm*
>>
>> I got nothing to say to you. Have you been on this list all this time
>> and still don't understand that Python sometimes optimizes immutables?
>
> Losing 'memory' of context Chris?
> Let me erm… remind:
>
> I said 'is' refers to "same in machine representation"
>
> Greg disagreed: « "is" in Python has an abstract definition that
>     doesn't depend on machine representation.»
>
> I said: In that case please restate the definition of 'is' from the manual which
> invokes the notion of 'memory' without bringing in memory.
>
> Steven gave his explanation by dropping 'memory' and gave a definition
>
> Which I showed does not match expected common sense
>
> Sure you can bring in the notion (now!) of optimization if you like
> But you cant have it both ways
> - 'is' is a fundamental conceptual notion of sameness
> - 'is' is a machine/implementation specific notion of sameness which changes
>   depending on machine/implementation specific decisions

Okay. Lemme spell it out for you real easy.

The 'is' operator tests if two things are the same thing.

Okay? With me so far? Good. No mention of memory.

Next, we have an optimization:

Sometimes, Python uses the same object more than once. You can't
distinguish one integer 1 from another other than by their ids, so
Python is free to use the same integer object for both uses of 1.

Clear? Still no mention of memory anywhere.

And it doesn't violate any conceptual notion of sameness.

ChrisA