Finding the instance reference of an object

[Steven D'Aprano]

On Mon, 27 Oct 2008 13:11:04 -0600, Joe Strout wrote:

> On Oct 27, 2008, at 12:19 PM, gooberts at gmail.com wrote:
> 
>> I think this "uncontrived" example addresses the C/Python difference
>> fairly directly (both were tested):
> 
> That's correct, but of course, C is a decades-old language barely a step
> above assembler.

So what? It's not like C is no longer in common use.

And even if C had disappeared off the landscape, there are millions of 
programmers, including beginning programmers, whose understanding of 
terms CBR and CBV are defined by the behaviour of languages like C and 
Pascal -- even if they haven't learned either language themselves.


> For a fair comparison, pick any modern OOP language,
> including the C derivatives (C++, Objective-C, Java), and compare a
> Python object to an object in that language, rather than to a struct.

But we already know that many such languages use the exact same calling 
convention as Python, so all you would be showing is that languages with 
the same calling convention as Python have the same calling convention as 
Python.

By common usage and technical definition, C is call by value. Argument 
passing in Python does not behave like C. So why insist that Python is 
also call by value?

[snip]

>> While yes, technically, it is true that those reference values must be
>> stored somewhere in memory, *that* is the implementation detail.
> 
> Agreed.  (And this was my point in response to someone arguing that no
> such location exists.)

Obviously any computer which is based on the Von Newman architecture of 
CPU plus memory is going to store the reference *somewhere*. That's a 
detail unimportant at the Python level. But since clockwork or Conway's 
"Life" cellular automata are both Turing complete, it would be possible 
to build a Python implementation where the reference values weren't 
localised to a particular place in memory, but distributed over the 
system. 


>> But is is not the *locations* of these references (i.e., the locations
>> of the Python *variables*) that are copied around, it is the references
>> themselves (the locations of the Python *objects*) that are copied.
> 
> Right.  The variables contain object references; these object references
> are copied (not referenced!) when you pass them into a function.  That's
> call by value.  In the case of an assignment, the reference is copied.

The value of a Python name is the Python object assigned to it, not an 
arbitrary memory location that points to the object. Even you would 
consider it obfuscatory if I executed this code:

x = "Norwegian Blue"

and then insisted that the value of x was "3086179808L, but if I run that 
line of code again it could get another value, and naturally if you run 
it on your computer you're almost certain to get a different value".

By your definition of "value=reference", the above is perfectly correct, 
and utterly, completely pointless, useless and unhelpful. It's rather 
like listing the ingredients of a cake as "Atoms". Technically true, but 
missing the point.



[snip]
> You are copying the object reference right onto the call stack.  This is
> pass by value, plain and simple.

Who *cares* about copying the pointers? That's the WRONG LEVEL. 
Ultimately EVERY programming language that runs on a computer with memory 
is "Copy By Bit Flipping", but it would be useless and unhelpful to tell 
people that every programming language uses the exact same calling 
conventions: "bits are flipped, and that's the end of story".


[snip]
> No Python method can do that, because Python arguments are ALWAYS passed
> by value.  There is no call by reference in Python.

Except that for millions of programmers who have learnt their terminology 
from Pascal and C, that implies that the values -- the data itself, not 
pointers to the data -- are copied. It implies that this can never fail:

x = [1]
y = function(x)
assert x == [1]

but of course it can fail, if function modifies x -- something which CBV 
implies can't happen.



> Period, end of story, nothing to see here.

I think that this entire argument hinges on the poverty of your mental 
toolbox. You have a hammer (call by value) and a screwdriver (call by 
reference) and refuse to accept that there could possibly be any other 
calling model. Hence you force any actual calling model into the 
framework of CBV or CBR, no matter how much violence you have to do to 
simple terms like "value" to make it fit.


-- 
Steven