Path: csiph.com!fu-berlin.de!uni-berlin.de!not-for-mail
From: Random832 <random832@fastmail.com>
Newsgroups: comp.lang.python
Subject: Re: I'm wrong or Will we fix the ducks limp?
Date: Sun, 05 Jun 2016 13:42:22 -0400
Lines: 64
Message-ID: <mailman.12.1465148550.2306.python-list@python.org>
References: <a1ff5170-e059-4379-b16a-d9eff8bc60a0@googlegroups.com> <87mvn22veg.fsf@rudin.co.uk> <13108bea-6750-443b-bee8-0532aba8b338@googlegroups.com> <CAG93HwG9pHJ_gtFcZhq5PCazwU4GTWeyqU8H=gLmoVR2h6-sUw@mail.gmail.com> <mailman.129.1464969297.1839.python-list@python.org> <c0c6b56a-64ac-4cb3-9ee1-076fdc12634b@googlegroups.com> <5753c89b$0$1616$c3e8da3$5496439d@news.astraweb.com> <1465148542.2670061.628500777.62F1EFE1@webmail.messagingengine.com>
Mime-Version: 1.0
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
In-Reply-To: <5753c89b$0$1616$c3e8da3$5496439d@news.astraweb.com>
Precedence: list
Xref: csiph.com comp.lang.python:109520

On Sun, Jun 5, 2016, at 02:37, Steven D'Aprano wrote:
> No they don't. You are confusing the implementation with the programming
> model.
> 
> Following the assignment:
> 
> x = 99
> 
> if you print(x), do you see something like "reference 0x12345"? No.
> 
> Do you have to dereference that reference to get the value of x? No.
>
> At the Python level, the value of x is 99, not some invisible,
> untouchable reference to 99.

Sure, but that is the value of the object referenced by x, it is not a
property of x itself.

x = y = 999; z = int('999')
x is y # True
x is z # False

How would you describe the difference between x and y, and z? This is
not a mere implementation detail [though, the fact that for int in
particular I had to go higher than 99 to get this result is - I wouldn't
have had this problem with strings, and I *couldn't* have had this
problem with lists]. The fact that two objects can have the same value
while being different objects, and that two variables can point to the
same object, are part of the programming model. Immutable objects do
tend to blur the line, since implementations are permitted to make them
the same even when they're apparently independent.

The fact that == is an operator distinct from 'is' inherently means that
variables contain references, not objects.

There is, obviously, only one value in my example. If variables
contained objects, then my example would have three objects, none more
or less distinct. They contain references, and that is the only way
there are two objects, and that is the only model in which there are two
of anything.

[but, hey, at least we can agree that Python has variables.]

> There is no analog to dereferencing in Python, nothing like print(x^).

I don't see where anyone said there was. I think you've inferred meaning
to the statement "python variables contain references" that it does not
actually have.

> You bind values (that is, objects)

Values are not objects. x and z have the same value, and their objects
are identical but distinct, but they are different because they point
(or refer, or by your weird terminology "bind") to different objects.

> directly to names, and names (variables) hold their value, not a
> reference to their value.

They hold a reference to an object. The object holds the value.

> The fact that for some implementations that is implemented using
> references of some sort or another (e.g. pointers in CPython) is an
> implementation detail which is irrelevant to the language and its
> execution model.