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

[Joe Strout]

On Nov 7, 2008, at 12:13 PM, Terry Reedy wrote:

> 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'.

I actually rather like "identifier," though it seems a little too  
technical for casual use.  On the other hand, "label" seems too  
arbitrary -- "variable" is a common term, and accurate enough to me.

> '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.

Did I?  What were they?  I thought I had a clear idea what I mean by  
it (and, as far as I know, it's consistent with what everybody else  
means by it too).  The only oddity in Python is that things you might  
not expect to be variables (such as module names) actually are.  But  
that's a succinct way to express that observation; saying "module  
names are variables too" seems to imply all the right things (e.g.  
that you can assign new values to them, or assign them to other  
variables).

>> 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.
>
> To me, this implies that the corresponding parameter should become a  
> reference to that reference value.

Really?  You've just described passing an object reference by  
reference.  If "passing a reference by value" implies adding an  
additional reference to it, then what would "passing a reference by  
reference" mean to you? And, examining your thought process, can you  
explain where that implication came from?

>  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.

Yes, but that would happen ONLY when they also think that a variable  
actually contains the object data.  And since there are many here  
trying to claim exactly that, I think that is the root cause of the  
problem, not calling parameter passing "by value."

And this belief (that the value of a variable is an object) leads to  
other mistaken beliefs too, such as that assignment should make a copy:

   x = y
   x.foo = bar

Anyone surprised by the list mutation inside a function should also be  
surprised to find that y.foo = bar.  I think we should simply address  
the root cause of that confusion, not try to redefine their  
understanding of how parameters are passed, and ALSO redefine what  
assignment means.

>> 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'.

Sure, that's fine.  It doesn't really matter how it's implemented.   
What matters is that a name or collection slot somehow refers to an  
object, and whatever the form of that reference is, it is copied (*)  
to the LHS of an assignment or to the formal parameter of a function  
call.

(*) I was going to say "transferred" but when something is transferred  
from A to B, it implies that B gains it and A loses it.  "Copied" has  
the right implication: that afterwards, both A and B now have it.

> >  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'.

Perhaps this is the two meanings you mentioned above.  I'm not sure I  
see any useful dichotomy here, though.  In C, we say that this  
variable is an integer, that variable is a character, the one over  
there is a double.  This is unambiguous shorthand for "the declared  
type of this variable is such-and-so", and each such variable contains  
data of that type.  So there's no harm in saying that a variable is an  
integer, or that a variable contains an integer, as the context  
requires.

In Python, AFAICT, there is only one type, the object reference.  So,  
the type of every variable is 'reference', and each one contains a  
reference.

>  Whereas a name (noun) definitely *is* a reference and not a  
> container.

Yes, I'll grant you that about it.  "Label" and "identifier" has that  
connotation as well.  But as long as we recognize that what a Python  
variable contains is a reference, I don't see that it matters.  And  
this is a very useful recognition, since it implies the correct things  
about assignment and 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.

Fine with me.  (I've also seen "formal parameter" and "actual  
parameter" respectively, but hey, I'm flexible.)

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

Super, that's great, but not very helpful, at least to someone who  
knows any other programming language.  For them, it's better to point  
out that it does what those other languages routinely do when they  
assign an expression to an identifier.

>> 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.

Could be.

Maybe we could run such an experiment at PyCon, pulling in non- 
attendees from the hallway and getting them to take the test in  
exchange for a free donut or coffee.

Best,
- Joe