Explanation of list reference

[Steven D'Aprano]

On Sat, 15 Feb 2014 18:29:59 +0200, Marko Rauhamaa wrote:

> Steven D'Aprano <steve+comp.lang.python at pearwood.info>:
>> On Sat, 15 Feb 2014 14:07:35 +0200, Marko Rauhamaa wrote:
>>> Steven D'Aprano <steve+comp.lang.python at pearwood.info>:
>>>> On Sat, 15 Feb 2014 12:13:54 +0200, Marko Rauhamaa wrote:
>>>>>    5. id(x) == id(y) iff x is y
>>>>
>>>> # Counter-example
>>>> py> x = 230000
>>>> py> idx = id(x)
>>>> py> del x
>>>> py> y = 420000
>>>> py> idy = id(y)
>>>> py> idx == idy
>>>> True
>>> 
>>> I don't accept that as a counterexample.
> 
>> Why?
> 
> Nowhere do I see the violating "x is y".

Do you truly think that there is even the tiniest, most microscopic 
chance that the int 230000 which has been garbage-collected and no longer 
exists, and the int 420000, are the same object?



>> All I need to do is show a case where two distinct objects have the
>> same ID.
> 
> How do you know objects are "distinct"? Myself, I would use the "is"
> test.

I know objects are distinct if they are objects with different values, 
such as 230000 and 420000, due to the fundamental fact that ints cannot 
have the value 230000 and 420000 at the same time. I leverage my 
knowledge that ints are intended to model the mathematical integers, and 
while that model is not perfect, it is not so bad as to have 230000 and 
420000 be the same number.

I also know that objects are distinct if one of them has been garbage 
collected, on the account of it no longer existing.


>>> That's the point. I don't think id() and "is" have any abstract
>>> meaning on top of the formal axioms.
>>
>> Who is talking about "abstract meaning"?
> 
> I am. I mean, "implementation-independent".

"Abstract meaning" does not mean "implementation independent". The 
definition of identity given in the documentation is both implementation 
independent and concrete: identity is tied concretely to the creation of 
the object, while still leaving implementations free to choose exactly 
how they tie identity to creation.


>> Object identity is simple and well-defined in Python. I don't know why
>> you are so resistant to this. Read the documentation.
> 
> It is not defined at all:
> 
>    Every object has an identity, a type and a value. An object’s
>    identity never changes once it has been created; you may think of it
>    as the object’s address in memory. The ‘is‘ operator compares the
>    identity of two objects; the id() function returns an integer
>    representing its identity.
> 
> Thus "x and y are identical" *means* "x is y" and nothing else.

You are correct, "x and y are identical" does mean that "x is y". That is 
exactly the point.

However, the `is` operator is not necessarily the same as the English 
word "is". Is some languages, the `is` operator is a synonym for the 
equals operator. That is not the case in Python. In Python, the 
*expression* `x is y` has the same meaning as the English sentence "x is 
y" in the strong sense of testing identity, rather than the weak sense of 
merely testing similarities (or metaphor). So the Python docs don't 
merely give a circular definition, they distinguish between two different 
and competing possibilities:

(1) The `is` operator means the same as the == operator. (NO)

(2) The `is` operator tests for object identity. (YES)


Please also see my response to Roy Smith's message.

Every object has a unique (during the lifetime of the object) identity. 
The specific nature of that identity is implementation-dependent, and 
strictly irrelevant. The `is` operator tests whether the two operands are 
the same object, that is, whether they have the same identity. That's all 
it does.



-- 
Steven