Finding the instance reference of an object [long and probably boring]

[Terry Reedy]

Joe Strout wrote:
> On Nov 6, 2008, at 10:35 PM, Steve Holden wrote:

> Note: I tried to say "name" above instead of "variable" but I couldn't 
> bring myself to do it -- "name" seems to generic to do that job.

Python has two types of names.  Some complex objects -- modules, 
classes, and functions, and wrappers and subclasses thereof, have 
'definition names' that are used instead of a 'value' to print a 
representation.  Otherwise, names are identifiers, the term used in the 
grammar.

But I agree even two meaning is one too many.  Maybe 'label' would be a 
better short form for 'identifier'.  'Labeling' might be clearer for 
many beginners than 'name-binding'.

 >  Lots
> of things have names that are not variables: modules have names, classes 
> have names, methods have names, and so do variables.  If I say "name," 
> an astute listener would reasonably say "name of what"

Common nouns, when instantiated, become the name of whatever particular 
object they are associated with.

> -- and I don't 
> want to have to say "name of some thing in a name space which can be 
> flexibly associated with an object" when the simple term "variable" 
> seems to work as well.

'Variable' has many more meanings than 'name' or 'label' and overall 
seems to be more confusing, not less.  I say this as an empirical 
observation of c.l.p postings.  You yourself switched back and forth 
between two different meanings.

> I'm with you there.  To me, the consistent simplicity is exactly this: 
> all variables are object references, and these are always passed by value.

The me, this implies that the corresponding parameter should become a 
reference to that reference value.  In any case, the last 10 years of 
this newsgroups shows that describing Python calling as 'by value' 
confuses people so that they are surprised that mutating a list inside a 
function results in the list being mutated outside the function.

> But Python doesn't have those simple types, so there is a temptation to 
> try to skip this generalization and say that references are not values, 

The Python Language Reference uses the word 'reference' but does not 
define it.  I take it to be 'whatever information an interpreter uses to 
associate a name or collection slot with an object and to retrieve the 
object (and possibly its value) when requested'.

> Well of course.  I'm pretty sure I've said repeatedly that Python 
> variables refer to objects on the heap.

Built-in objects are not allocated on the heap.

>(Please replace "heap" with "object space" if you prefer.)

They are in abstract object space, although CPython occasionally leaks 
the abstraction in error messages about not being able to modify 
non-heap objects.

 >  I'm only saying that Python variables
> don't contain any other type of value than references.

One problem with the word 'variable' is that variables are somethings 
thought of as 'containing', as you did above.  So you switch back and 
forth between 'variables *are* references' and 'variables *contain* 
references'.  Whereas a name (noun) definitely *is* a reference and not 
a container.

> Ditto right back at you.  :)  So maybe here's the trouble: since all 
> Python variables are references,

Back to *is*.

> But continuing to attempt to gloss over that fact, when you come to 
> parameter passing,

I believe most of us here try to follow Knuth's lead and use 'parameter' 
for the local names and 'argument' for the value/object that gets 
associated with the name.

> not copied).  You also have to describe the assignment operator as 

In Python, assignment is not an operator by intentional design.

> different from all other languages, since clearly that's not copying the 
> object either.

Python's assignment *statement* does what we routinely do in everyday 
life when we assign new labels to things, whether permanently or 
temporarily.

 > An assignment copies the RHS
> reference into the LHS variable, nothing more or less.

Back to variable as container.
An assignment associates the RHS object(s) with the LHS target(s).

 > A parameter  copies the argument reference into the formal parameter,

A function call associates objects derived from the argument expressions 
and stored defaults with the function parameters.

> Isn't that simple, clear, and far easier to explain?

Applied to my version, I agree ;-).


> I wonder if that could be tested systematically.  Perhaps we could round 
> up 20 newbies, divide them into two groups of 10, give each one a 1-page 
> explanation either based on passing object references by-value, or 
> passing values sort-of-kind-of-by-reference, and then check their 
> comprehension by predicting the output of some code snippets.  That'd be 
> very interesting.

Except for your garbling of the alternative to your version, I agree.
I suspect that different people might do better with different 
explanations, depending on background.

> In my case, my understanding of Python became clear only once I stopped 
> listening to all the confusing descriptions here, and realized that 
> Python is no different from other OOP languages I already knew.

Whereas I learned Python without any OOP experience but enough knowledge 
of C++ to know I did not want to go there.

Terry Jan Reedy