I'm wrong or Will we fix the ducks limp?

[Steven D'Aprano]

On Mon, 6 Jun 2016 02:08 pm, Random832 wrote:

> On Sun, Jun 5, 2016, at 23:52, Steven D'Aprano wrote:
>> Certainly not. x = y = 999 is required to bind the same object to x and
>> y.
> 
> My statement was that if two variables can be bound to the same object,
> then variables *cannot* contain objects. The object has to exist
> somewhere,

I could dispute that assertion, e.g. consider what happens when you simulate
a Python interpreter in your brain. What is the location of the objects
then? As best as we can tell from neuroscience, memories are distributed
across fairly large swaths of neurons.

But that's not the point. Even if you were right that objects must exist at
a single well-defined location, that is strictly irrelevant. That's
implementation, not interface. There is nothing in the specification of the
Python virtual machine and the execution model that requires objects have a
single location. That's just the way they happen to be easy to write on
current generation computers.


> and this requirement means that the variables cannot be where 
> the objects live.

I don't care. That's just implementation. There is nothing in the Python
programming language that says "x = 999" makes x an indirect reference to
999. The very thought is absurd.

I have tried to see things from your perspective. I completely agree that,
at the implementation level, Python variables are implemented as references
(in CPython, pointers) to objects. We all agree on that. Yay! We have
partial agreement!

But it really, truly is absurd to insist that AT THE PYTHON LEVEL variables
are references. That's as foolish as insisting that the President of the
United States is two words with eleven letters, not a man.

Surely you can acknowledge that the language we use to explain things will
depend on the level of physical phenomena we are looking at? If we can't
agree on that, then there's no point in continuing this conversation.

At the Python virtual machine level, x is the object 999. This is the most
important level, because we're actually talking about Python code. The
whole point of this is to understand what the Python VM does, so we can
reason about code. Every thing else is, in general, obfuscation, to a
lesser or greater degree.

At the C implementation level, x is an entry in a hash table, a pointer
pointing at an object in the heap. Occasionally it is useful to bring the
discussion down to this level, but not often.

At the assembly language level, x is probably a 32-bit or 64-bit word,
depending on whether you have a 32-bit or 64-bit build. Assigning to a
variable is a matter of copying memory from one location to another.

At a lower level still (machine code? microcode?), we don't copy memory, we
flip bits. x will be a series of bits. There's not much interesting to say
at this level: whether x is 999 or a HTTPServer object or None, it's still
just a series of bits.

At the hardware level, considered as a DRAM unit (other types of memory use
different implementations), x is a set of microscopic capacitors holding
tiny electric charges representing either a "high" or "low" charge, i.e.
bits.

At the hardware level below that, we have to start talking about the
properties of impure silicon, electrons in atomic shells, so-called
electron holes, etc. Given x = 999, x will be any of a large number of sets
of electron distributions, involving millions(?) of electrons. A few
thousand more or less in any one specific chunk of silicon will make no
difference: there are many, many physical states that x could be.

And below that, we start talking about quantum probability functions, and
surely we can agree that it is absurd to say that Python variables are
really quantum probability functions!

Can you at least met me there? Can we agree that, while it is absolutely
true and correct that Python variables are really implemented as quantum
waves, this fact is of absolutely no use to anyone trying to understand
what a snippet of Python code does?



>> If your variable x were a reference, then we would expect type(x) to
>> return
>> something like "Reference", but it doesn't, it returns int.
> 
> No we would not. You are once again inferring meaning that people's
> statements don't actually carry.

In the plain English meaning of the words, if is an int, then it behaves as
an int, and if you use introspection on it, it will look like an int. If x
is a string, then it similarly behaves as, and looks like, a string. So if
x is a reference, what should it behave as? A wheelbarrow?

I cannot help that you want to describe x as being a reference while denying
that it behaves as a reference or can be introspected as looking like a
reference. You could equally say it is really, actually a set of bits, or
charges in an integrated circuit, or electrons in atomic shells.


-- 
Steven