<html>
<body>
Hi John,<br><br>
I think what we all agree on is the details of what is happening in
Python. As long as we use unambiguous words to describe that
process, there is no problem. The problem is in the definition of
"call-by-value". I have offered a simple definition, what
I called the "traditional" definition, but perhaps that is
claiming too much priority for one tradition. I'll call it the
"common" definition, what most programmers will tell you, and
what you find at
<a href="http://en.wikipedia.org/wiki/Call_by_value" eudora="autourl">http://en.wikipedia.org/wiki/Call_by_value</a><br><br>
I know this discussion is getting very old, but I would like to get just
one thing resolved. Can you give us clear and concise definitions
of call-by-value and call-by-reference?<br><br>
At 03:59 PM 5/20/2008 -0500, John Zelle wrote:<br><br>
<blockquote type=cite class=cite cite>Hi David,<br><br>
It's enough for me at this point that we all agree on what we're
talking<br>
about. The rest is a matter of "taste," I think. The one real
sticking<br>
point I still have with your approach is simply that what you
"expect"<br>
pass-by-value to do in Python (namely make a copy of the object that
a<br>
variable refers to) is not to my knowledge implemented in any
language.</blockquote><br>
C does call-by-value, at least with primitive objects (according to
Kernighan and Ritchie).<br><br>
<blockquote type=cite class=cite cite>Lots of languages have been built
around "pass-by-value," and none is<br>
doing what you consider your acid-test for pass-by value. On the
flip<br>
side, any language that claims pass-by-reference as part of the
language<br>
allows me to do what I consider the acid test for pass-by-reference<br>
(namely I can change the referent of the calling argument), which I<br>
cannot do in Python.</blockquote><br>
I assume by "change" you mean "re-bind", and by
"referent" you mean "object". It is possible to
modify the object of the calling argument.<br><br>
<blockquote type=cite class=cite cite> So I prefer to use the terms
the way they have been<br>
used historically and remain consistent with language design<br>
traditions.</blockquote><br>
I'm finding it hard to understand your terms, perhaps because I'm not
familiar with the traditions you refer to. It would really help if
we could use the same words for simple things we all understand.
Here are my suggestions.
<dl>
<dd>variable:(name, pointer) --> object:(type, value, address)
<dd>re-bind a variable
<dd>modify an object
<dd>copy a pointer
</dl>-- Dave<br><br>
<br>
<blockquote type=cite class=cite cite>On Tue, 2008-05-20 at 10:29 -0700,
David MacQuigg wrote:<br>
> Hi John,<br>
> <br>
> I did some more searching on this question, and I see it has been
discussed many times before. I read a few of the threads, and they
seem to go on forever with no resolution, just a lack of
communication. It comes down to the definition of
"value". One camp says a value is only the actual data in
an object, the other says the value can be the reference. I've been
using it to mean only the data.<br>
> <br>
> variable:(name, pointer) --> object:(type,
value, address)<br>
> <br>
> Looks like this controversy is not just in the Python
community. I found a good discussion in Bruce Eckel's Thinking in
Java, 2nd ed, Appendix A: Passing and Returning Objects. On p.
1018, he has a discussion of pass-by-value with a nice summary of the
views of "two distinct camps". He concludes with "I
will attempt to sidestep the issue. In the end, it isn't that
important. What is important is that you understand that passing a
reference allows the caller's object to be changed
unexpectedly."<br>
> <br>
> I think that is what we need to focus on. What will students
remember in later years? Which explanation will be most beneficial
in helping them avoid problems?<br>
> <br>
> I hope that you will recognize the validity of other views, and not
just say they are wrong. I think that is the only way this
discussion can move forward.<br>
> <br>
> I wrote a detailed response to your last post, but decided to delete
most of it. I'll just leave a few parts where I need to correct a
serious misunderstanding of what I am saying.<br>
> <br>
> At 06:36 PM 5/19/2008 -0500, John Zelle wrote:<br>
> <br>
> >You insist on writing/thinking/reasoning as if Python
variables<br>
> >"contain" the objects they refer to, but that simply
is not the case for<br>
> >the traditional use of the term "variable."<br>
> <br>
> That is not at all what I meant. In my model the variable has
only a name and a pointer. The variable refers to an object, but it
does not "contain" the object, in the sense that a variable in
C is like a box containing a value.<br>
> <br>
> variable:(name, pointer) --> object:(type,
value, address)<br>
> <br>
> > Literally, your model,<br>
> >with the traditional definition would require that every
assignment<br>
> >statement in Python create a new variable. Consider this
sequence:<br>
> ><br>
> >a = 3 # creates the variable "a"<br>
> >a = 4 # "a" is now bound to another location<br>
> >a = 5 # "a" is now bound to yet another location<br>
> ><br>
> >Since the address of the value changes with each assignment, the
pair<br>
> >(name, location) is changing each time, and hence we have here
three<br>
> >different variables with the same name. That's certainly not the
way I<br>
> >think about what's happening in Python!<br>
> <br>
> In my model, the pointer associated with the variable named
"a" is moved from one object to the next, leaving the old
object for the garbage collector.<br>
> <br>
> >So, my question is why don't we just stick with the traditional
notion<br>
> >of a variable being a (name, location) pair.<br>
> <br>
> I've been calling it a (name, pointer) meaning the same thing.<br>
> <br>
> > Realize that Python<br>
> >dereferences the values for us when we use variables in
expressions and<br>
> >stop trying to invent new names for a parameter passing
mechanism that<br>
> >is identical in function to traditional call by value.<br>
> <br>
> We seem to be coming from different traditions. In my
tradition, call-by-value means copying the actual data to the function,
and call-by-reference means copying a reference (pointer). These
definitions include all possibilities, and lead to simple inferences
about safety and efficiency, which is the only benefit I can see for
discussing the topic with students who are nowhere near being language
theory specialists. The message to my students will be simple -
It's like call by reference in C - efficient, but watch out for functions
that might modify the objects you send as arguments.<br>
> <br>
> The alternative - like call by value but ... seems a lot more
difficult to explain.<br>
> ... but it is efficient, because the "values" being passed
are really just pointers.<br>
> ... but it is not safe, because the function can modify the caller's
arguments.<br>
> <br>
> When I first learned Python, four years ago, I found the discussion
in Martelli's book on call-by-value to be confusing, so much so that it
impeded my understanding of the simple mechanism that it really is.
This confusion was not resolved until last week when I started
researching this question, in response to a student's question in
class. I believe that telling students of C that Python is
"call by value" will generate the same confusion that I
suffered. No amount of explanation, or re-assurance "this is
what some experts say" will help.<br>
> <br>
> The examples and diagrams in your section 6.5.2 are excellent.
Just for fun, I re-wrote that section keeping everything the same, but
changing only the few paragraphs where you talk about
call-by-value. In my humble opinion, that section is shorter and
much more clear from a "call-by-reference" point of view.
It avoids having to say that the "values" of variables are
actually the pointers, not the data. It avoids introducing more
complex definitions (e.g. "call-by-reference" means that
assigning a value to a formal parameter changes the value in the calling
program. That's a result, not a definition, and the result depends
on unrelated details of the language, like re-binding semantics.)
It avoids the awkward "Isn't that interesting?" paragraph where
you have to explain that in some cases you really can change the caller's
object after it has been passed by value.<br>
> <br>
> I'm not saying your definitions are wrong, I just don't see the
benefits of adopting these more difficult and more specialized
definitions. Being consistent with some language theorists is not a
benefit if it confuses students.<br>
> <br>
> -- Dave</blockquote></body>
</html>