Objects in Python

[Steven D'Aprano]

On Fri, 24 Aug 2012 08:00:59 +1000, Chris Angelico wrote:

> On Fri, Aug 24, 2012 at 3:56 AM, Steven D'Aprano
> <steve+comp.lang.python at pearwood.info> wrote:
>> But name bindings are a kind of variable. Named memory locations are a
>> *different* kind of variable. The behaviour of C variables and Python
>> variables do not follow the Liskov Substitution Principle -- you can't
>> rip out the entire "names bound to objects" machinery of Python and
>> replace it with C-like named memory locations without changing the
>> high- level behaviour of Python. And so by some ways of thinking it is
>> *wrong* to treat name bindings and memory locations as "the same sort
>> of entity". Hence, if C variables are variables, then Python name
>> bindings can't be.
> 
> Yet Python's variables are extremely close to C's pointer variables.

Not really. Pointer variables are no different from any other variable: 
you have a named memory location that contains some data. In this case, 
the data happens to be a link to another chunk of memory. The pointer 
variable itself is just a named location containing data, same as a char 
variable, a float variable, etc. The data is a pointer rather than a char 
or float, and the operations which you can do to pointers are different 
to those you can do to chars or floats, but that's true of any data type.

In languages without pointers, like Fortran 77, you can more or less 
simulate them with a fixed array of memory as the heap, with integer 
indexes into that array as pointers. These "pointer variables" are no 
different from other "integer variables" except in the meaning you, the 
programmer, gives them. This is no different from how C or Pascal treat 
pointers, except that those languages have syntactical support for 
pointer operations and Fortran 77 doesn't.


> If
> you allocate all your "real data" on the heap and do everything with
> pointers, you'll have semantics very similar to Python's

You're confusing two different levels of explanation here. On the one 
hand, you're talking about C semantics, where you are explicitly 
responsible for managing unnamed data via indirection (pointers). 
Typically, the *pointers* get given names, the data does not.

On the other hand, you talk about Python, where you have no access at all 
to the pointers and memory addresses. You manage the data you actually 
care about by giving them names, and then leave it up to the Python 
virtual machine to transparently manage whatever indirection is needed to 
make it work.

The fact that the end result is the same is hardly surprising -- Python's 
VM is built on top of C pointer indirection, so of course you can start 
with pointers and end up with Python semantics. But the practice of 
coding are very different:

* in C, I care about identifiers ("names") in order to explicitly manage 
addresses and pointers as a means to reach the data I actually care about;

* in Python, I care about identifiers in order to reach the data I 
actually care about.



-- 
Steven