why cannot assign to function call

[Joe Strout]

Mark Wooding wrote:

>>>> The `they're just objects' model is very simple, but gets tied up in
>>>> knots explaining things.  The `it's all references' model is only a
>>>> little more complicated, but explains everything.
>>> But it *over* explains, because it implies things that "everybody knows"
>>> about references in other languages that aren't true for Python.
> 
> I addressed this elsewhere.  Summary: `pass-by-reference' is a different
> thing to `all you manipulate are references': Python does pass-by-value,
> but the things it passes -- by value -- are references.

Quite right.  It's easy to see this in languages where some types are 
references and others are simple values; and even easier in such a 
language that supports both pass-by-value and pass-by-reference (such as 
REALbasic or VB.NET).  Then you can easily see, in one language, all 
combinations of [value type, reference type] * [pass by ref, pass by val].

In Python, we only have reference types, and we only have pass by value, 
so out of the four combinations above, there is only one: references 
passed by value.  You'd think this would make it easier, but from the 
raging debates and repeated obfuscation on this point, it apparently 
makes Python MORE difficult to understand and explain (at least for some).

> I agree with the comment about Pascal, but C is actually pretty similar
> to Python here.  C only does pass-by-value.  If you want a function to
> modify your variable, you have to pass a pointer value which points to
> it.

Right -- a C/C++ pointer is (or at least, can be in normal usage) pretty 
similar to a reference (though of course you can do more low-level and 
hackish things with them too).  In C, such a reference is always passed 
by value, as in Python or Java, and just like the default mode in RB or 
.NET.  In C++, you can also choose to pass such a parameter by 
reference, like the ByRef mode in RB and .NET.  This parameter passing 
mode is unavailable in Python or Java.

>>> Okay, the abstraction has leaked again... are the paperweights references
>>> to the objects, or the names we've bound objects to? I'm confused...
> 
> They're the references to the objects.  You don't bind names to
> objects.  You bind names slots in which you store references.

Well put (again).  This is technically the correct description, though 
in casual usage, I think it's fine to occasionally gloss over some of 
these layers as long as everyone involved understands what is meant. 
(This is especially true when the references are to immutable objects, 
which are functionally very similar to simple values.)

>> How do we decide what is best for newcomers to Python, depending on
>> background?
> 
> That I really don't know.  I'm not good at teaching total beginners
> (does it show?) because I'm too enmired in the theory. ...

FWIW, I've spent a fair amount of time teaching beginners, though not so 
much in Python yet.  But plenty of time in other languages where the 
same questions come up.  In my experience, pointing out that a variable 
of any object type contains a *reference* to that object, rather than 
the object data itself, and then illustrating with a couple of examples, 
quickly clears up any confusion.  I've never had a newbie require more 
than a couple of exchanges on this topic before they get it.  (And 
before I joined the Python community, I never even felt the need to 
actually draw a picture [1] to make it clearer.)

> What I am pretty sure of is that references are going to have to enter
> the picture at some point, because other models get too complicated.

I agree completely.  I can barely understand the other models myself.

Best,
- Joe

[1] http://www.strout.net/info/coding/valref/