Finding the instance reference of an object

[Steven D'Aprano]

On Thu, 06 Nov 2008 09:59:37 -0700, Joe Strout wrote:

> that's
> pretty much the whole point: that variables in Python don't contain
> objects, but merely contain references to objects that are actually
> stored somewhere else (i.e. on the heap).

You're wrong, Python variables don't contain *anything*. Python variables 
are names in a namespace. But putting that aside, consider the Python 
code "x = 1". Which statement would you agree with?

(A) The value of x is 1.

(B) The value of x is an implementation-specific thing which is 
determined at runtime. At the level of the Python virtual machine, the 
value of x is arbitrary and can't be determined.

If you answer (A), then your claim that Python is call-by-value is false. 
If you answer (B), then your claim that Python is call-by-value is true 
but pointless, obtuse and obfuscatory.



> This is explicitly stated in
> the Python docs [1], yet many here seem to want to deny it.

> [1] http://www.python.org/doc/2.5.2/ext/refcounts.html


You have a mysterious and strange meaning of the word "explicitly". Would 
you care to quote what you imagine is this explicit claim?



>> Looks to me that even if there were ten levels of indirection you would
>> still
>> insist that its a "pass by value" because in the end, its the actual
>> memory
>> address of the first pointer in the queue that is passed.
> 
> No, it's entirely possible for an OOP language to have pass by
> reference, and, to put it your way, this adds one more level of
> indirection.  Look at the C++ and RB/VB.NET examples at [2].  But Python
> and Java do not offer this option.

Yes, you are right, Python does not offer pass by reference. The 
canonical test for "call by reference" behaviour is to write a function 
that does this:

x = 1
y = 2
swap(x, y)
assert x == 2 and y == 1

If you can write such a function, your language may be call-by-reference. 
If you can't, it definitely isn't c-b-r. You can't write such a function 
in standard Python, so Python isn't c-b-r.


The canonical test for "call by value" semantics is if you can write a 
function like this:

x = [1]  # an object that supports mutation
mutate(x)
assert x == [1]

If mutations to an argument in a function are *not* reflected in the 
caller's scope, then your language may be call-by-value. But if mutations 
are visible to the caller, then your language is definitely not c-b-v.

Python is neither call-by-reference nor call-by-value.

 
>> If that is what you mean, it is obviously trivially true - but then ALL
>> calling can only be described as "call by value" - which makes nonsense
>> of what the CS people have been doing all these years.
> 
> That would indeed be nonsense.  But it's also not what I'm saying. See
> [2] again for a detailed discussion and examples.  Call-by-value and
> call-by-reference are quite distinct.

And also a false dichotomy. 


>> "Calling by value" is not a useful definition of Pythons behaviour.
> 
> It really is, though.  You have to know how the formal parameter relates
> to the actual parameter.  Is it a copy of it, or an alias of it?

And by definition, "call by value" means that the parameter is a copy. So 
if you pass a ten megabyte data structure to a function using call-by-
value semantics, the entire ten megabyte structure is copied.

Since this does not happen in Python, Python is not a call-by-value 
language. End of story.


 
> Without knowing that, you don't know what assignments to the formal
> parameter will do, or even what sort of arguments are valid. Answer:
> it's a copy of it.  

Lies, all lies. Python doesn't copy variables unless you explicitly ask 
for a copy. That some implementations of Python choose to copy pointers 
rather than move around arbitrarily large blocks of memory instead is an 
implementation detail. It's an optimization and irrelevant to the 
semantics of argument passing in Python.



> Assignments don't affect the actual parameter at
> all.  This is exactly what "call by value" means.

Nonsense. I don't know where you get your definitions from, but it isn't 
a definition anyone coming from a background in C, Pascal or Fortran 
would agree with.




-- 
Steven