Apology Re: Is 'everything' a refrence or isn't it?

[Patrick Maupin]

Mike Meyer wrote:
> This is where we disagree. I think their understanding of references
> is dead on. What's broken is their understanding of what variables are
> and what assignments mean. Once you fix that, the rest falls into
> place.
>
> (Steven D'Aprano wrote:)
> > The fact that call by object is unfamiliar is precisely its advantage.
> > Instead of people jumping to conclusions about what it means, like they do
> > with "reference", they will stop and think and if need be look for further
> > information about Python's object model. At the very least, they won't say
> > "Everything in Python is a reference, so this should work, but it
> > doesn't".
>
> What you're advocating is intentionally misleading people to deal with
> a symptom. I'd rather give them enough truth to deal with the disease.

I agree completely.  I have personally "converted" around a half-dozen
or so coworkers to Python over the course of the last three or four
years.  The conversion takes place in stages.  Usually, I have written
a small script for them which they later want to enhance, so they come
to me for a tutorial session.

My initial 5-10 minute tutorial starts off with an explanation of
name-binding, including something like "a=[1,2,3]; b=a; a[1]=4; print
b; b=42; print a, b".  Note that this also demonstrates the dynamic
nature of Python typing -- 'b' is not restricted to being bound to a
list merely because the first time it was bound was to a list.

Once they have that down, I describe "immutable" vs. "mutable".  I
start off by explaining that of course integers are immutable because
you cannot change 1 into 5.  I then explain (with examples) that,
additionally, in the language, strings are immutable (which does NOT
mean you cannot usefully manipulate them, just that, for example, in "x
= 'abc'; x = x + 'd'" the manipulation "x + 'd'" results in a
completely new string. (The attempted example x[1] = "d" also gets them
used to the exception reporting mechanism.)

I actually spend more time (of this 10 minutes!)  on "immutable" vs.
"mutable" (including ancillary lessons) than I spend on anything else.
After showing that strings are immutable, I then explain that tuples
are a sort of immutable list.  This usually elicits the question of why
such a thing is needed, which is a great segue into a minute or so
spent on dictionaries and their keys. (Dictionaries can occupy
additional time if the student recognizes that they are a good fit for
a pressing need.)

Only about the last 30 seconds or so is spent on function calling.  I
explain that all parameters are passed by reference, but that
OBVIOUSLY, if the called function wants to alter the caller's object,
the referenced object must be mutable, because, JUST AS WITH C
POINTERS, the pointer to the object is passed by making a copy of it on
the stack, so there is no way that the callee can directly alter the
caller's own pointer to the object.

After this lesson, I send them back to look at their script with
information about the online docs and a standing offer to help them
over any rough spots.  NOT ONE PERSON has ever been confused about the
parameter passing.

I have only given these tutorials to accomplished programmers, so my
opinion about teaching newbies is not as well-formed, but for a
C/C++/assembler programmer, the REAL question about parameters is "What
is pushed onto the stack?"  They are capable of a high level of
abstraction, so all they really want to know "Is a COPY of the object
passed on the stack, or is a POINTER to the object passed on the
stack?"

With such an accomplished student, if the teacher described Python's
parameter passing as anything but "call by reference",  it would lead
to confusion, and, ultimately, disrespect for the teacher.

Regards,
Pat