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
--
http://mail.python.org/mailman/listinfo/python-list
