John, This is the best explanation I've heard so far for why Python is "call by value", but it still leaves me dissatisfied that what I thought was simple (call-by-value) is really complicated and not very useful to me, and what is truly simple (passing a copy of the object) is a useful concept with no name. I also wonder if I'm completely misunderstanding the Wikipedia article (and other texts like K&R - Kernighan and Ritchie p. 27), or if there aren't two schools of thought with conflicting terminology.
As usual, the confusion in the discussion arises when there are differing underlying assumptions, unstated and unrecognized. I was assuming the word "value" referred to a part of the object in the simple scheme - variable:(name, pointer) --> object:(type, value, address). I see now that "value" can mean the pointer, and that making a copy of the pointer can be passing a "value". Perhaps we should refer to the object as having (type, data, address) and save the word "value" for the meaning you assume. At 10:55 AM 5/6/2008 -0500, John Zelle wrote: >David, > >Actually, I don't think there is that much confusion among the folks who >understand/design/study programming languages. Python uses call by >value, period, as that term is technically used. But your note below >shows the continued confusion (among programmers) about what parameter >passing terminology. In classifying calling mechanisms, the question is >what happens with a variable being passed and the value it (contains in >the traditional usage of those words); it has nothing to do with >objects. When modeling Python semantics, a variable actually holds a >reference (pointer, address) of an object. When the variable is passed >as a parameter, its value (the reference/pointer) is copied into the >formal parameter variable. That's it. It's call by value. Understood now. The value is the pointer, not the data. >The confusion and fuzzy thinking comes because the automatic >dereferencing of Python variables when they are used in expressions >leads people to think about objects being "stored in" variables. Then >they talk about whether objects being copied or not copied in function >call parameters. But an object is _never_ stored into a Python >variable. Never any misunderstanding for me. >To see the difference between passing a mutable object in Python vs. a >reference parameter in other languages, you just have to ask if you can >change the value of the calling code's variable by assigning a value to >the corresponding formal parameter in a function. With your definition of "value", it never changes. The assignment creates a new local variable in the function's namespace. > In C++ or Pascal, >setting the value of a reference parameter actually changes the contents >of the variable in the calling program. Understood, but now we are using the previous definition of "value". If we use the definition above, changing the "value" just points the parameter name in the function to some other address. In C if I have a parameter (int *x) then x is the address of an int. The actual value passed is an address, and an assignment statement in the function can change the data at that address. But it is still "call-by-value" according to K&R, since the value in this case is an explicit address, with 32 bits of data looking just like an unsigned integer. >def func(formal_param): > # change the value of formal_param to be a reference to foo_object > formal_param = foo_object > >x = bar_object >func(x) ># for pass by reference, x would now contain a foo_object ># In Python (pass by value) x is still bar_object. > >In Python, you cannot change the actual parameter variable (x above). No >matter what you do in the function, the actual parameter still contains >the same thing, a reference to the same object it was always pointing to >at the time of call. That's because the function operates on it own copy >of that reference, not the _actual_variable_ of the caller. > >Summary: Python's parameter passing is just call by value. But Python >variable values are always references and Python semantics dictates that >those values are dereferenced when variables are used in expressions. >That leads some programmers to (imprecisely) talk about parameter >passing in terms of variables having objects as values. I often do this >loosely myself, because it's easy to think of a Python name as a >variable that stores and object. When I hear "variable x has value y" I think of x pointing to object y, not storing y, not even loosely. My confusion is not due to misunderstanding what Python actually does. It seems like there might be a simple alternative to the traditional definition of "call-by-value" in terms of result rather than mechanism. The traditional definition (K&R) is simple if you think of mechanism. The new definition is simple if you think of result (argument in calling program not changeable by the called function). Should we add a note to that Wikipedia page? -- Dave >On Tue, 2008-05-06 at 07:45 -0700, David MacQuigg wrote: >> I agree, there is no reason to dig into call-by-??? terminology with new >> "untainted" programmers. The sticky-note analogy is all we need for these >> students. The figures in Michael's book are excellent. >> >> However, having been tainted by C, I am finding the discussion interesting. >> I just don't understand why there is so much confusion with these call-by >> terms. Does the function get a copy of the object or a reference to the >> original object? It's got to be one or the other. >> >> At 10:11 PM 5/5/2008 -0500, Michael H.Goldwasser wrote: >> >> > Python's model is quite clean, it just doesn't match up perfectly >> > with the standard call-by-??? terminology. >> >> In call-by-reference evaluation, a function receives an implicit reference >> to the argument, rather than a copy of its value. >> -- http://en.wikipedia.org/wiki/Call_by_value >> >> By this definition, Python's model is call-by-reference, even though the >> reference (pointer) is not seen by the user. C's model is call-by-value, >> even though that value can be an explicitly-evaluated address (pointer). >> >> -- Dave >> >> >> _______________________________________________ >> Edu-sig mailing list >> Edu-sig@python.org >> http://mail.python.org/mailman/listinfo/edu-sig >> _______________________________________________ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig