Finding the instance reference of an object

[Steven D'Aprano]

On Fri, 17 Oct 2008 15:39:33 -0600, Joe Strout wrote:

> On Oct 17, 2008, at 3:19 PM, Grant Edwards wrote:
> 
>>> And my real point is that this is exactly the same as in every other
>>> modern language.
>>
>> No, it isn't.  In many other languages (C, Pascal, etc.), a "variable"
>> is commonly thought of as a fixed location in memory into which one can
>> put values.  Those values may be references to objects.
> 
> Right, though not in languages like C and Pascal that don't HAVE the
> notion of objects.  We really ought to stop bringing up those dinosaurs
> and instead compare Python to any modern OOP language.

You really should stop assuming that languages still in use are 
"dinosaurs". There are many, many people whose understanding of such 
terms as "call by value" or "variable" are based on C or Pascal or even 
Fortran.

Besides, while the Pascal language itself doesn't have objects, plenty of 
Pascal implementations do.


>>  In Python, that's not how it works.  There is no
>> "location in memory" that corresponds to a variable with a particular
>> name the way there is in C or Pascal or Fortran or many other
>> languages.
> 
> No?  Is there any way to prove that, without delving into the Python
> source itself?

>>> x = 1
>>> id(x)  # a unique identifier, in CPython equal to its address
135536432
>>> x = 2
>>> id(x)
135536420

Notice that the address of x changes. Actually, that's a lie. The name 
'x' doesn't have an address, except in the sense that the string 'x' must 
occur somewhere in memory. But that's an unimportant implementation 
detail. In reality, what we see is:

the object 1 is bound to the name 'x';
we ask for the id() of the object bound to 'x' (1), which is 135536432;
the object 2 is bound to the name 'x';
we ask for the id() of the object bound to 'x' (2), which is 135536420.

That's what is happening at the Python level of code. Anything else is 
just implementation details.



> If not, then I think you're talking about an internal implementation
> detail.

Namespaces aren't an internal implementation detail, they are fundamental 
to how Python works.


>> All that exists in Python is a name->object mapping.
> 
> And what does that name->object mapping consist of?  At some level,
> there has to be a memory location that stores the reference to the
> object, right?

Who cares? That's the *wrong* level. At *some* level, everything is just 
flipping electrons from one state to another, but I think even you would 
object if I claimed that:

"All computer languages are call-by-flipping-electrons, with no 
exceptions."


Somebody could implement a Python interpreter using literal post-it notes 
for names and literal boxes for objects. The fact that our CPUs are 
optimized for flipping bits instead of (say) water flowing through tubes, 
or clockwork, or punching holes in paper tape, is irrelevant. When 
discussing what Python code does, the right level is to discuss the 
Python virtual machine, not the implementation of that VM.

If you want to discuss the deeper levels, it's perfectly acceptable to 
say that the CPython implementation uses memory locations holding 
pointers. But that's not *Python*, that's hidden detail that the Python 
programmer can't reach.



>>> Nothing unusual here at all (except that some of us here seem to want
>>> to make up new terminology for standard behavior, perhaps in order to
>>> make Python seem more exotic).
>>
>> That's because it is fundamentally different from what happens in
>> languages like C.
> 
> What happens in a modern OOP language is just as fundamentally different
> (which is to say, not really very much) from what happens in C or
> FORTRAN or COBOL, too.

Which is why modern OOP languages like Python shouldn't use the same 
terminology invented to describe what Fortran and Pascal do.


> If you make up new terms like "rebinds," 

This is not something that is just "made up", it is an actual description 
of what the Python VM does.


> well, I guess at least that
> avoids giving the listener the wrong idea.

As opposed to call-by-value, call-by-reference, and "call-by-value-where-
the-value-is-the-reference", all of which do give the listener the wrong 
idea.


> Instead it gives them no
> idea at all, which may be better, but not as good as giving them the
> right idea.

But it is the right idea. They just don't know what it means, because 
they've been listening to people like you who insist on using Pascal 
terminology with a definition unrecognizable to Pascal programmers. To an 
ex-Pascal programmer like myself, when you talk about "call by value 
where the value is a reference", it sounds to me as if you are insisting 
that cars are ACTUALLY horse and buggies, where the horse is the engine, 
why are we inventing new terms like 'automobile', that just confuses 
people.



> It still leaves them to investigate what actually happens,
> and ultimately they will find that the parameters are always passed by
> value in Python.

But they aren't. When you call a function, the arguments are not copied 
before being passed to the function.



> May as well save them the trouble and point that out
> up front.

Well, sure, if you want to be misleading and confusing.



> And how many recovering FORTRAN or C programmers do we get around here,
> anyway?  

Enough.

It's not just people who have programmed Pascal, but those whose 
understanding of CBV and CBR have been shaped by ancient half-remembered 
Pascal lessons.


> Java is what they've been teaching in school for the last
> several years, and it was C++ for a good decade before that.

Have they really? Which school is that?

My company has hired a part-time young gun programmer. He's still at Uni, 
doing Comp Sci, and has *far* wider IT experience than the average 
programmer his age. His skills? PHP, Perl, C, oh and he's just starting 
to learn C++ this semester.

There are plenty of programmers who have never been to university or 
collage, and even some who have never learnt programming in school at 
all. Believe it or not, it's not compulsory.



-- 
Steven