why cannot assign to function call

[Aaron Brady]

On Jan 9, 9:30 am, Joe Strout <j... at strout.net> wrote:
> Aaron Brady wrote:
> > Possible compromise.  You can think of functions as mutation-only.
> > You pass the object, and it gets a new (additional) name.  The old
> > name doesn't go in.  </compromise>
>
> That's correct.  The reference itself is passed in, not the variable (or
> expression) that held or generated the reference in the calling code.

This is very odd, and I see it quite a bit.
Me: "You pass the object."
Joe: "That's correct.  You pass the reference."

What was wrong with my original?

> This is true.  (Technically, instead of variable, we should say "LValue"
> here -- there are things slightly more complex than simple variables
> that can serve as the left-hand side of an assignment.  So replace
> "variable" with "lvalue" above if you prefer.)

This is a point worth making.  I want to penny-pinch every term in an
introductory text, though, so, it's a tough call.

> M2: If 'fun()' returned a reference, you might be able to mutate the
> object that refers to.
> m2: You can sometimes mutate the object it refers to.
> C2: 'fun()' returns a reference.

This is horrendous.
http://en.wikipedia.org/wiki/Formal_fallacy
http://en.wikipedia.org/wiki/Affirming_the_consequent

A question: Are you Joe and you Mark certain that the simplest
possible introductory explanation makes use of the term 'reference'?
Perhaps we can have a contest for shortest/simplest/best description
of Python's data/variable/argument model.

Lastly, I don't see any reason why we couldn't make both explanations
available.  'For those coming from Java/etc....; for those coming from
C++/etc.....'  They would both get read.