why cannot assign to function call
joe at strout.net
Sat Jan 10 20:49:48 CET 2009
Aaron Brady 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?
I'm saying that I believe your idea was correct, but worded imprecisely
(IMHO of course). So I restated what I believed you were saying, using
terminology which I believe to be more precise. If nothing else, this
gives you the opportunity to say "No, that's not what I meant at all."
>> 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.
I did point out that the logic was incorrect (even though the
conclusion, in this case, happens to be true).
> 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.
Sure -- but it judging it might be difficult, requiring some newbies and
a test to check their comprehension (as you and I pondered once before).
> 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.
Yes, except that the reference explanation applies equally well to
anyone coming from Java, C/C++, RB, VB.NET, and probably others... I'm
not sure to whom the other explanation would appeal, unless perhaps it's
LISP programmers (just a guess, since those on that side of the aisle
seem to invoke LISP more frequently).
More information about the Python-list