On Fri, 31 Oct 2008 13:58:13 +1300, greg wrote: > Dale Roberts wrote: > >> Okay, you can have it that way, but every time you explain to someone >> that Python passes "By Value", you will have to add the additional >> baggage that, oh, by the way, there is a completely different meaning >> for "value" in Python than what you are used to. > > For what it's worth, I happen to agree that telling someone that Python > passes parameters "by value" without being sure they understand exactly > what "by value" means,
"By value" is very simple. It means a copy of the value is passed to the function. Using "call by value" to mean "pass a copy of a reference to the value" is an abuse of terminology, because that's exactly what happens in call by reference: a copy of the reference to the value is passed. > is not a good idea -- not because the term isn't > well-defined, but because of the widespread confusion out there about > it. Well duh. All these people trying to insist that after executing x=1 the value of x is some arbitrary memory location are certainly confused. > But equally I wouldn't tell someone that it's *not* by value, because if > they do happen to correctly understand what it means, that will confuse > them just as much. But it isn't call by value. Why wouldn't you tell people it is when the value isn't being copied? > So my recommendation is just to tell them that it works by assigning the > result of evaluating the actual parameter to the formal parameter. And 99% of them will just say "What?". That's not an explanation, it's obfuscation at its worst. What *is* the result of evaluating the actual parameter? Is it a reference to the object or the object itself? Is it a copy of the object? A shallow copy? A deep copy? Not a copy at all? What implications for behaviour does it have? What does it mean? > If they understand how assignment works in Python, that tells them all > they need to know. Nonsense. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
