On Jan 9, 9:30 am, Joe Strout <j...@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. -- http://mail.python.org/mailman/listinfo/python-list
