Objects in Python

[Evan Driscoll]

On 08/24/2012 05:00 AM, Steven D'Aprano wrote:
> No. The compiler remembers the address of 'a' by keeping notes about it
> somewhere in memory during the compilation process. When you run the
> compiled program, there is no longer any reference to the name 'a'.
>
> ...
>
> The mapping of name:address is part of the *compilation* process -- the
> compiler knows that variable 'x' corresponds to location 12345678, but
> the compiled code has no concept of anything called 'x'. It only knows
> about locations. The source code 'x = 42' is compiled into something like
> 'store 42 into location 12345678'. (Locations may be absolute or
> relative.)
>
> In languages with name bindings, the compiler doesn't need to track
> name:address pairs. The compiled application knows about names, but not
> about addresses. The source code 'x = 42' is compiled into something like
> 'store 42 into the namespace using key "x"'.
What you describe is sorta correct, but it's also not... you're 
describing implementations rather than the language. And while the 
language semantics certainly impose restrictions on the implementation, 
I think in this case the situation is closer than you acknowledge:


 From the Python side, I suspect that for most functions, you'd be able 
to create a Python implementation that behaves more like C, and 
allocates locals in a more traditional fashion. I don't know much about 
it, but I'd guess that PyPy already does something along this line; 
someone also mentioned that Cython (admittedly not a full-blown Python 
implementation, but close for the purpose of this question) tries to do 
the same thing.


On the C side, imagine a function with locals x, y, and z which never 
takes the address of any of them. (You said later that "Just because the 
public interface of the language doesn't give you any way to view the 
fixed locations of variables, doesn't mean that variables cease to have 
fixed locations.")

First, C variables may not even have a memory address. They can 
disappear completely during compilation, or live in a register for their 
entire life.

Second, it's possible that those variables *don't* occupy a fixed 
location. If you never explicitly take an address of a variable (&x), 
then I can't think of any way that the address can be observed without 
invoking undefined behavior -- and this means the C compiler is free to 
transform it to anything that is equivalent under the C semantics. In 
particular, it can split uses of a variable into multiple ones if there 
are disjoint live ranges. For instance, in:
     x = 5
     print x
     x = 10
     print x
there are two live ranges of x, one consisting of lines 1 and 2, and one 
consisting of lines 3 and 4. These live ranges could have been different 
variables; I could just of easily have written
     x = 5
     print x
     y = 10
     print y
and these pieces of code are observationally equivalent, so the compiler 
is allowed to generate the same code for both. In particular, it could 
either compile the second example to share the same memory address for x 
and y (meaning that a memory address isn't uniquely named by a single 
variable) or it could compile the first to put the two live ranges of x 
into different memory addresses (meaning that a variable doesn't 
uniquely name a memory address). In fact, I'd *expect* an optimizing 
compiler to share memory for x and y, and I'd also expect to be able to 
concoct an example where different live ranges of one variable wind up 
at different addresses. (The latter I'm less sure of though, and I also 
expect it'd be a little hard, as you'd have to come up with an example 
where even at the high optimization levels you'd need to see that, both 
live ranges would wind up in memory.)

Third, and more wackily, you could technically create a C implementation 
that works like Python, where it stores variables (whose addresses 
aren't taken) in a dict keyed by name, and generates code that on a 
variable access looks up the value by accessing that dict using the name 
of the variable.

Evan