Finding the instance reference of an object

Steven D'Aprano steve at REMOVE-THIS-cybersource.com.au
Tue Nov 4 17:54:04 EST 2008


On Tue, 04 Nov 2008 09:16:05 -0800, Craig Allen wrote:

> When you consider the status of the entity "x" in "x=1" in python, it is
> a pointer, and python looks like pass by value.

Nonsense. Python doesn't have pointers. You're letting Joe confuse you. 
Python has objects: *everything* in Python is an object, and you have no 
access to pointers. Everything else is an implementation detail, and that 
is subject to change between implementations.


> The need for a different name comes from the fact that using pointers
> ubiquitously like this leads to behavior much more like pass by
> reference.

And the confusion strikes again... you've just said that "Python looks 
like pass by value", and now you say that Python's behaviour is "much 
more like pass by reference". Can you not see that this is a 
contradiction?


> I'm open to pass-by-sharing, or pass-by-object, but neither is
> perticularly intuitive, not as obvious in meaning as pass-by-val or
> pass-by-reference (or call-by-xxx).

There's nothing "intuitive" about call-by-reference or call-by-value 
either, they are modes of behaviour that need to be learned. And even if 
we accept that somehow people are born with in inherent knowledge of how 
C++ passes function parameters, that certainly doesn't apply to what Joe 
is peddling: that the value of a variable is an arbitrary and hidden 
reference to the actual value you want.


> I suppose I'd like pass-by-name as
> more a description, as "name" to me has a similar sense to pointer, at
> least in a language that preserves the name as a runtime entitity
> (making C/C++ languages which compile away names).

Pass-by-name already has a meaning, and it isn't what Python does.

Craig, please ignore all the implementation-specific details of how the C-
implementation of Python works. That's not Python-the-language. 
IronPython works differently, so does Jython, so does PyPy. In fact, 
IronPython exposes to the Python programmer .Net objects where call-by-
reference is actually correct (or so I'm told).

At the level of Python code, Python operates on *objects*. When you call 
a function with an argument, the argument (an object) is NOT copied, it 
is passed to the function. If you mutate the argument inside the 
function, you are changing the object and the caller will see the 
mutation: this is just like call-by-reference, and unlike call-by-value. 
But if you assign a different object to the argument name, the caller 
does NOT see the change, which is just like call-by-value. So depending 
on what type of object the argument is, and depending on what you do 
inside the function, you get something that looks rather like call-by-
value or call-by-reference semantics. But what the Python VM does is the 
same no matter what you do: Python's calling model is different from 
either byval or byref. The accepted name for that calling model is "call-
by-sharing", or sometimes "call-by-object" or even "call-by-object-
sharing", and it goes back at least to 1974 and the CLU language, and 
arguably even older than that to Lisp.



-- 
Steven



More information about the Python-list mailing list