Finding the instance reference of an object

[Steven D'Aprano]

On Thu, 16 Oct 2008 11:24:28 -0600, Joe Strout wrote:

> On Oct 16, 2008, at 10:59 AM, Larry Bates wrote:
> 
>>> how do i find that the name is 'bob'
>>
>> Short answer is that you can't.  This because Python's names (bob) are
>> bound to objects (modulename.objectname()).  They are NOT variables as
>> they are in "other" programming languages.
> 
> Which other programming languages?  I've never seen an OOP language that
> didn't work the same way as Python.
> 
> However, 'bob' here really is a variable.  It's a variable whose value
> (at the moment) is a reference to some object.


Traditionally, a "variable" is a named memory location.

The main objection I have to using "variable" to describe Python name/
value bindings is that it has connotations that will confuse programmers 
who are familiar with C-like languages. For example:

def inc(x):
    x += 1

n = 1
inc(n)
assert n == 2

Why doesn't that work? This is completely mysterious to anyone expecting 
C-like variables.

At this point people will often start confusing the issue by claiming 
that "all Python variables are pointers", which is an *implementation 
detail* in CPython but not in other implementations, like PyPy or Jython.

Or people will imagine that Python makes a copy of the variable when you 
call a function. That's not true, and in fact Python explicitly promises 
never to copy a value unless you explicitly tell it to, but it seems to 
explain the above, at least until the programmer starts *assuming* call-
by-value behaviour and discovers this:

def inc(alist):
    alist += [1]  # or alist.append(1) if you prefer
    return alist

a = [1, 2, 3]
b = inc(a)
assert a == [1, 2, 3]

Are functions call by value or call by reference???

(Answer: neither. They are call by name.)


I myself often talk about variables as shorthand. But it's a bad habit, 
because it is misleading to anyone who thinks they know how variables 
behave, so when I catch myself doing it I fix it and talk about name 
bindings. Noobs might not know what that means, but that's a feature, not 
a bug, because it gets them paying attention instead of making faulty 
assumptions.

Of course, you're entitled to define "variable" any way you like, and 
then insist that Python variables don't behave like variables in other 
languages. Personally, I don't think that's helpful to anyone.

[snip]
> Well, they are variables.  I'm not quite grasping the difficulty here...
> unless perhaps you were (at first) thinking of the variables as holding
> the object values, rather than the object references.

But that surely is what almost everyone will think, almost all the time. 
Consider:

x = 5
y = x + 3

I'm pretty sure that nearly everyone will read it as "assign 5 to x, then 
add 3 to x and assign the result to y" instead of:

"assign a reference to the object 5 to x, then dereference x to get the 
object 5, add it to the object 3 giving the object 8, and assign a 
reference to that result to y".

Of course that's what's really happening under the hood, and you can't 
*properly* understand how Python behaves without understanding that. But 
I'm pretty sure few people think that way naturally, especially noobs. 
References are essentially like pointers, and learning pointers is 
notoriously difficult for people. Python does a magnificent job of making 
references easy, but it does so by almost always hiding the fact that it 
uses references under the hood. That's why talk about variables is so 
seductive and dangerous: Python's behaviour is *usually* identical to the 
behaviour most newbies expect from a language with "variables".



-- 
Steven