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.
Agreed.
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
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'?
I am.
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).
Best,
- Joe
--
http://mail.python.org/mailman/listinfo/python-list
