Finding the instance reference of an object

[Steven D'Aprano]

On Fri, 17 Oct 2008 09:56:17 -0600, Joe Strout wrote:

> On Oct 16, 2008, at 11:23 PM, Dennis Lee Bieber wrote:
> 
>> On Thu, 16 Oct 2008 21:19:28 -0600, Joe Strout <joe at strout.net>
>> declaimed the following in comp.lang.python:
>>
>>> Now that IS mysterious.  Doesn't calling a function add a frame to a
>>> stack?  And doesn't that necessitate copying in values for the
>>> variables in that stack frame (such as 'x' above)?  Of course we're
>>
>>    No -- it copies the /reference/ to the object containing the value.
> 
> The reference to the object IS the value of an object reference
> variable.  

That's a bizarre and unnatural way of looking at it. To steal a line from 
the effbot, that's like valuing your child's Social Security number over 
the child herself:

http://mail.python.org/pipermail/python-list/2003-May/204560.html


If we execute a line of Python code:

x = "parrot"

and then ask "What's the value of x?", I think that even you would think 
I was being deliberately obtuse, difficult and obfuscatory if I answered 
"location 0xb7cdeb2c".


> So good, parameters are passed ByVal in Python as they appear
> to be, and as is the default in every other modern language.

Nonsense. Python doesn't copy a parameter before passing it to the 
function. You get the same parameter inside the function as outside:

>>> def foo(x):
...     print id(x)
...
>>> a = ['some', 'thing']
>>> print id(a); foo(a)
3083441036
3083441036


I'm going to anticipate your response here: you're going to deny that 
call by value implies that the list ['some', 'thing'] will be copied 
before being passed to the function. According to *some* definitions of 
CBV, you might even be right. But according to *other* definitions, 
including the one that I learned in comp sci at university, that copying 
of data is an essential part of CBV.

These other definitions aren't necessarily a formal definition from some 
Computer Scientist. They're just as likely to be informal understandings 
of what CBV and CBR mean: "if it's call by value, don't pass big data 
structures because they will be copied and your code will be slow".


>> Just as assignment transfers the reference to the RHS object to the
>> name
>> shown on the LHS.
> 
> Assignment copies the RHS value to the LHS variable.  In the case of an
> object reference, the value copied is, er, an object reference.

No, assignment binds an object to a name. That's what Python does.

Of course, at the implementation level, name binding might be implemented 
by copying object references. Or it might not. That's an implementation 
detail that isn't relevant at the Python level.

Or at least, it shouldn't be relevant until the abstraction leaks.
http://www.joelonsoftware.com/articles/LeakyAbstractions.html



[snip]
> For object references (including the mutable ones that may treat people
> up), Python's behavior is no different from any other language.

That's an exceedingly broad claim. No different from Java? Well, perhaps. 
No different from Lisp? Doubtful. No different from Forth? Yeah, riiight.

Speaking of Java, there's one major difference between Java and Python 
with respect to names. In a statically typed language like Java, you 
define names before you use them, and from that point the name is bound 
to both a type and an object. But the binding to the object is optional, 
and such unbound names are said to be null.

In a dynamically typed language like Python, names are bound only to 
objects. You can't have an unbound name: if a name exists, it must be 
bound to an object, and if it doesn't exist, you get a NameError 
exception when you try to access it. And objects are typed, not names.

http://www.ferg.org/projects/python_java_side-by-side.html



 
>>>> (Answer: neither. They are call by name.)
>>>
>>> I have no idea what that means.  They're call by value as far as I can
>>> tell.  (Even if the value may happen to be a reference.)
>>
>> 	Technically, as I recall the definition of "call by name", they
>> aren't that either. ...
>> Call by name, then, acted as a macro expansion wherever the argument
>> was referenced in the called function.
> 
> Thanks for that explanation.  Clearly that's not what's going on in
> Python.

Ah no, that's my bad. I have a strange and disturbing mental stutter that 
substitutes "call by name" when I mean to say "call by object" at the 
most embarrassing times. Sorry.




-- 
Steven