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 -- https://mail.python.org/mailman/listinfo/python-list
