passing by refference
Daan Hoogland
I'd like the following code to print
1
instead of
2
<file name="D.py">
def spam(**ni):
ni["egg"] = 1;
bacon = 2
spam(egg = bacon)
print bacon
</file>
the actual construct is going to return several newly created object, to give a
reason why.
Peter Maas
> is passing by reffence possible in python?
No, not directly. You can embed values in a container
(list, dictionary, object) and use the container as
argument. List example:
def spam(aList):
aList[0]=4
eggs = [1 2 3]
spam(eggs)
print eggs # prints [4 2 3]
Mit freundlichen Gruessen,
Peter Maas
--
-------------------------------------------------------------------
Peter Maas, M+R Infosysteme, D-52070 Aachen, Hubert-Wienen-Str. 24
Tel +49-241-93878-0 Fax +49-241-93878-20 eMail peter...@mplusr.de
-------------------------------------------------------------------
Batista, Facundo
Python!!
If you want to return a lot of objects, just return them!!
Example:
Python 2.1.1 (#1, Jan 6 2003, 16:05:24)
[GCC 2.96 20000731 (Red Hat Linux 7.3 2.96-110)] on linux2
Type "copyright", "credits" or "license" for more information.
>>> def funct(number):
... return range(number)
...
>>> values = funct(5)
>>> values
[0, 1, 2, 3, 4]
>>> print values
[0, 1, 2, 3, 4]
>>> print "\n".join([str(val) for val in values])
0
1
2
3
4
>>>
If you feel that you can't, just send one example.
. Facundo
#- -----Mensaje original-----
#- De: Daan Hoogland [mailto:hoog...@astron.nl]
#- Enviado el: Martes 13 de Mayo de 2003 11:00 AM
#- Para: pytho...@python.org
#- Asunto: passing by refference
#-
#-
#- is passing by reffence possible in python?
#-
#- I'd like the following code to print
#- 1
#- instead of
#- 2
#-
#- <file name="D.py">
#- def spam(**ni):
#- ni["egg"] = 1;
#-
#- bacon = 2
#- spam(egg = bacon)
#- print bacon
#- </file>
#-
#- the actual construct is going to return several newly
#- created object, to give a
#- reason why.
#-
#- --
#- http://mail.python.org/mailman/listinfo/python-list
#-
Mel Wilson
Everything in Python is passed by reference. But the
references are frequently references to values. In these
cases, an assignment works by binding a different value from
the value that was bound before. With work, a reference to
a mutable object can get you the effect of another
language's "call by reference". You probably know this, but
you may not have worked out all the consequences.
>I'd like the following code to print
>1
>instead of
>2
>
><file name="D.py">
>def spam(**ni):
> ni["egg"] = 1;
>
>bacon = 2
>spam(egg = bacon)
>print bacon
></file>
Here you've created a dictionary object: {'egg':2} and
bound it with the name "ni" in the namespace for "spam".
You've modified this dictionary to {'egg':1}, but when spam
exits, there are no other references to it and the dictionary
falls out of scope and vanishes.
>the actual construct is going to return several newly created object, to give a
>reason why.
The Way To return multiple objects is to return multiple
objects:
def spam ():
return 1, 2, 3
bacon, kippers, fried_bread = spam ()
print bacon
What you want to do can be done, for the right value of
"what you want to do".
Regards. Mel.
Joshua Marshall
> In article <mailman.105283514...@python.org>,
> Daan Hoogland <hoog...@astron.nl> wrote:
>>is passing by reffence possible in python?
> Everything in Python is passed by reference.
...
This is incorrect terminology. Python has call-by-value semantics,
not call-by-reference (it is not possible to pass a reference to a
variable into a function).
Brian Quinlan
In the sense that you mean, no.
It is hard to say exactly what idiom you want, since your example is
clearly contrived. It is possible to write a function such as this:
def spam(*args):
# process args in some way
return args
bacon, egg = spam(bacon, egg)
Cheers,
Brian
Terry Reedy
"Joshua Marshall" <joshway_wi...@myway.com> wrote in message
news:b9r933$8q0$1...@ginger.mathworks.com...
To me, call-by-value implies a copy operation, which Python does not
do. I think call-by-assignment or call-by-name-binding is more
accurate. Given a definition "def f(parname1, parname2): <body>" and
a call "f(exp1, exp2)" the interpreter evaluates expressions exp1 and
exp2 as usual and then binds parname1 and parname2 to the resulting
objects, but in the local namespace of f instead of in the namespace
where the expressions were evaluated. A function call is like a
series of cross-namespace assignment statements. Once this is
understood, the effect of modifying mutable arguments is
understandable.
Terry J. Reedy
...
Chris Liechti
uhm...
>>> def f(x):
... print id(x)
...
>>> a=5
>>> id(a)
3328264
>>> f(a)
3328264
>>>
as you can clearly see, the reference to the same object is passed into the
function. but its rebound to a new name in the function. assiging to that
name just rebinds a new reference to that name, which has no influence on
the callers namespace.
for out-parameters its an usual practice to use a list:
>>> def f(x):
... x[0] = 2
...
>>> a = [1]
>>> f(a)
>>> a
[2]
>>>
altough out-parameters are seldom used in python as we can have multimple
return values, as Mel Wilson and others pointed out.
chris
--
Chris <clie...@gmx.net>
Joshua Marshall
...
> To me, call-by-value implies a copy operation, which Python does not
> do. I think call-by-assignment or call-by-name-binding is more
> accurate. Given a definition "def f(parname1, parname2): <body>" and
> a call "f(exp1, exp2)" the interpreter evaluates expressions exp1 and
> exp2 as usual and then binds parname1 and parname2 to the resulting
> objects, but in the local namespace of f instead of in the namespace
> where the expressions were evaluated. A function call is like a
> series of cross-namespace assignment statements. Once this is
> understood, the effect of modifying mutable arguments is
> understandable.
> Terry J. Reedy
See
http://wombat.doc.ic.ac.uk/foldoc/foldoc.cgi?call-by-value
What you describe is call-by-value. There is an implicit copy of the
arguments passed to a function, though not a deep-copy. The values
that are being copied are often references.
Joshua Marshall
> Joshua Marshall <joshway_wi...@myway.com> wrote in
> news:b9r933$8q0$1...@ginger.mathworks.com:
...
>> This is incorrect terminology. Python has call-by-value semantics,
>> not call-by-reference (it is not possible to pass a reference to a
>> variable into a function).
> uhm...
>>>> def f(x):
> ... print id(x)
> ...
>>>> a=5
>>>> id(a)
> 3328264
>>>> f(a)
> 3328264
>>>>
> as you can clearly see, the reference to the same object is passed into the
> function. but its rebound to a new name in the function. assiging to that
> name just rebinds a new reference to that name, which has no influence on
> the callers namespace.
I said that it's not possible to pass a reference to a /variable/ into
a function. What has been passed to f is not a reference to a
variable, it's a reference to an integer.
Aahz
Joshua Marshall <joshway_wi...@myway.com> wrote:
>
>What you describe is call-by-value. There is an implicit copy of the
>arguments passed to a function, though not a deep-copy. The values
>that are being copied are often references.
Depends whether you consider the arguments to be the binding contained by
a target or the object being passed in by the binding; if the latter,
you're wrong. More than that, you're completely wrong about "often
references"; what gets passed in to a function parameter is *always* a
binding.
Note that I'm using "binding" instead of "reference"; like the mistaken
use of "call-by-value", "reference" has semantics that make sense in
other languages, but not in Python.
--
Aahz (aa...@pythoncraft.com) <*> http://www.pythoncraft.com/
"In many ways, it's a dull language, borrowing solid old concepts from
many other languages & styles: boring syntax, unsurprising semantics,
few automatic coercions, etc etc. But that's one of the things I like
about it." --Tim Peters on Python, 16 Sep 93
Donn Cave
...
| See
|
| http://wombat.doc.ic.ac.uk/foldoc/foldoc.cgi?call-by-value
|
| What you describe is call-by-value. There is an implicit copy of the
| arguments passed to a function, though not a deep-copy. The values
| that are being copied are often references.
That's a clever analysis - ``the values that are being copied are
often references'', indeed.
The only really 100% answer to this question - does Python pass by
value or by reference - is "No!" Then one can approach this subject
with a fresh mind unimpeded by the baggage of other programming
languages (and FOLDOC.)
The ``values that are being copied'' are _always_ references.
The result of an operation on this reference from within the function,
is identical to the same operation outside it - if I pass a parameter
"x" and then assign to it "x = 5", in either case, x is a reference
and I replace the original "x" with a new one. The only difference
is that the function and its caller bind to different namespaces.
Operations on the object - methods, indexing etc - apply to the original
object, namespace binding applies to the current namespace.
Is it call by reference, or call by value? No!
Donn Cave, do...@u.washington.edu
Joshua Marshall
> In article <b9rfpa$n45$1...@ginger.mathworks.com>,
> Joshua Marshall <joshway_wi...@myway.com> wrote:
>>
>>What you describe is call-by-value. There is an implicit copy of the
>>arguments passed to a function, though not a deep-copy. The values
>>that are being copied are often references.
> Depends whether you consider the arguments to be the binding contained by
> a target or the object being passed in by the binding;
I'm not sure what you mean by "binding contained by a target". A
binding is a pair: a variable and a value.
> if the latter, you're wrong.
I do mean that the arguments are objects. If you feel I'm wrong, it's
because we disagree about terminology. Though I've come to see that
meanings of "call-by-value" and "call-by-reference" used in c.l.py are
often non-standard.
> More than that, you're completely wrong about "often
> references"; what gets passed in to a function parameter is *always* a
> binding.
I'm not sure in what way you mean I'm wrong here. If you mean I
should have said "always references" instead of "often references", I
won't quibble.
> Note that I'm using "binding" instead of "reference"; like the mistaken
> use of "call-by-value", "reference" has semantics that make sense in
> other languages, but not in Python.
I believe it makes sense in Python (call-by-value), though I agree the
term "reference" might be misleading.
Doug Quale
> Note that I'm using "binding" instead of "reference"; like the mistaken
> use of "call-by-value", "reference" has semantics that make sense in
> other languages, but not in Python.
Actually call-by-value makes sense in Python and its use here is not
mistaken. Call-by-value is the correct description of the semantics
of function calls in Python. There's nothing mystical or even in the
slightest bit unusual with the way that Python passes arguments.
Claiming that Python argument passing is not call-by-value is simply
wrong and leads to needless confusion.
The problem isn't really with how Python function calls work. Most
programmers seem to understand that just fine. The confusion ensues
because people often don't really understand what a value is. When
values are references call-by-value can seem to behave to some as
call-by-reference or even something else, but it's simply
call-by-value all the time. (In the Python Tutorial Guido suggests
using the term call-by-object-reference to describe this, but he
correctly states that Python is call-by-value.)
Confusion over argument passing isn't limited to Python. It's
remarkable how many programmers are convinced that although
call-by-value might explain argument passing in Pascal, their language
(Common Lisp, Scheme, C++, Python, etc.) must use some different
mechanism that those egghead computer scientists don't have a name
for. This comes up so very often that sometimes I think understanding
argument passing might be the Pons Asinorum of Computer Science.
Doug Quale
> Aahz <aa...@pythoncraft.com> wrote:
> > if the latter, you're wrong.
>
> I do mean that the arguments are objects. If you feel I'm wrong, it's
> because we disagree about terminology. Though I've come to see that
> meanings of "call-by-value" and "call-by-reference" used in c.l.py are
> often non-standard.
Don't worry -- Aahz is wrong, you're right ;-)
Call-by-value and call-by-reference don't have multiple meanings.
They are precisely defined terms in Computer Science. Unfortunately
people often substitute their own incorrect ideas about what cbv and
cbr mean, and not just in this group. It's a very common confusion.
Aahz
Doug Quale <qua...@charter.net> wrote:
>aa...@pythoncraft.com (Aahz) writes:
>>
>> Note that I'm using "binding" instead of "reference"; like the mistaken
>> use of "call-by-value", "reference" has semantics that make sense in
>> other languages, but not in Python.
>
>Actually call-by-value makes sense in Python and its use here is not
>mistaken. Call-by-value is the correct description of the semantics
>of function calls in Python. There's nothing mystical or even in the
>slightest bit unusual with the way that Python passes arguments.
>Claiming that Python argument passing is not call-by-value is simply
>wrong and leads to needless confusion.
Call-by-value is normally used when the values are explicitly passed.
In Python, the value that's being passed is implicit; you can't access
it directly. Period, exclamation point. The only thing you can do with
that value is assign it to a[nother] target or make method calls on the
object at the other end of the binding.
So while you're technically correct, I'll stick by my contention that
"call-by-value" causes more confusion than it saves.
Fredrik Lundh
> Call-by-value and call-by-reference don't have multiple meanings.
> They are precisely defined terms in Computer Science.
for some reason, CS folks tend to forget that most people live outside
the CS lab, in a world where words like "call", "value", and "reference"
have other, less precise meanings...
and the original question had nothing to do with any of this, of course.
</F>
Christopher A. Craig
> See
>
> http://wombat.doc.ic.ac.uk/foldoc/foldoc.cgi?call-by-value
>
> What you describe is call-by-value. There is an implicit copy of the
> arguments passed to a function, though not a deep-copy. The values
> that are being copied are often references.
If you look at
http://wombat.doc.ic.ac.uk/foldoc/foldoc.cgi?call-by-value
You will see that it also describes Python's calling strategy. Python
always passes the address of an argument variable rather than the
contents of said variable. That assignment will overwrite that
address is not related to the passing strategy.
--
Christopher A. Craig <list-...@ccraig.org>
"There is no subject, however complex, which--if studied with patience
and intelligence--will not become more complex." New Speaker's Handbook
Aahz
Christopher A. Craig <list-...@ccraig.org> wrote:
>
>If you look at
>http://wombat.doc.ic.ac.uk/foldoc/foldoc.cgi?call-by-value
>
>You will see that it also describes Python's calling strategy. Python
>always passes the address of an argument variable rather than the
>contents of said variable. That assignment will overwrite that address
>is not related to the passing strategy.
But reading
http://wombat.doc.ic.ac.uk/foldoc/foldoc.cgi?call-by-reference
illustrates why there is confusion and why call-by-value is a poor
phrase; "value of the argument expression" has no meaning in Python.
Consider:
def f(x):
print x
f(1+2)
f('1'+'2')
f([1] + [2])
The fact that you use the phrase "contents of said variable" in contrast
to "address of an argument variable" implies that you don't really
understand how Python works -- to the extent that there is a "variable"
at all, the content *is* the address. That confusion is precisely why I
and others prefer to use "name" and "binding".
Jeremy Hylton
If we care to debate terminology, then neither call-by-value nor
call-by-reference apply. Python has call-by-object semantics. As far
as I know, the first use of call-by-object was in a description of CLU.
Jeremy
Doug Quale
> Doug Quale wrote:
>
> > Call-by-value and call-by-reference don't have multiple meanings.
> > They are precisely defined terms in Computer Science.
>
> for some reason, CS folks tend to forget that most people live outside
> the CS lab, in a world where words like "call", "value", and "reference"
> have other, less precise meanings...
No, that's not true either. It isn't possilbe to forget that. People
like you remind us all the time.
Doug Quale
Python is call-by-value. The values are objects, but the argument
passing mechanism doesn't say anything about what values are in the
language.
Doug Quale
> In article <87vfwew...@charter.net>,
> Call-by-value is normally used when the values are explicitly passed.
I don't know what this means. In any case, it isn't true.
Call-by-value is the terminology that is accurately applied to
argument passing in Pascal, C, Lisp, Python and many other languages.
Values are quite different in Pascal and Lisp, but they use the same
argument passing mechanism.
> In Python, the value that's being passed is implicit; you can't access
> it directly. Period, exclamation point. The only thing you can do with
> that value is assign it to a[nother] target or make method calls on the
> object at the other end of the binding.
What has that to do with argument passing? You're describing the
characterstics of values in Python. Those characteristics apply even
to values that aren't passed as function arguments. You're not saying
anything about argument passing at all.
Tim Peters
>> If we care to debate terminology, then neither call-by-value nor
>> call-by-reference apply. Python has call-by-object semantics. As far
>> as I know, the first use of call-by-object was in a description of CLU.
[Doug Quale]
> Python is call-by-value. The values are objects, but the argument
> passing mechanism doesn't say anything about what values are in the
> language.
Sorry, that didn't make sense. It's true that, in CPython, pointers to
objects are passed under the covers, in C's call-by-value fashion, but
that's an implementation detail, and has no visible effect on the Python
language's semantics. Call-by-object really is the best description of
Python's semantics. If you do a literature search, you'll also see that
described as "call by object reference" and "call by sharing".
Call-by-value it ain't -- unless you view the implementation reference as
"the value", but that simply isn't helpful to anyone except Python's
implementors (of which Jeremy and I are two, BTW).
>>> def f(x):
... x[:] = [-1] * 3
>>> y = [1, 2, 3]
>>> f(y)
>>> y
[-1, -1, -1]
>>>
There's no rational sense in which that can be called call-by-value. A
similar program using C structs shows what call-by-value does mean:
#include <stdio.h>
struct s {
int x, y, z;
};
void display(const char* tag, struct s s) {
printf("%s %d %d %d\n", tag, s.x, s.y, s.z);
}
void f(struct s s) {
display("inside before", s);
s.x = s.y = s.z = -1;
display("inside after", s);
}
void main() {
struct s t = {1, 2, 3};
display("before", t);
f(t);
display("after", t);
}
Of course that displays:
before 1 2 3
inside before 1 2 3
inside after -1 -1 -1
after 1 2 3
Joshua Marshall
...
> Sorry, that didn't make sense. It's true that, in CPython, pointers to
> objects are passed under the covers, in C's call-by-value fashion, but
> that's an implementation detail, and has no visible effect on the Python
> language's semantics. Call-by-object really is the best description of
> Python's semantics. If you do a literature search, you'll also see that
> described as "call by object reference" and "call by sharing".
> Call-by-value it ain't -- unless you view the implementation reference as
> "the value", but that simply isn't helpful to anyone except Python's
> implementors (of which Jeremy and I are two, BTW).
>>>> def f(x):
> ... x[:] = [-1] * 3
>>>> y = [1, 2, 3]
>>>> f(y)
>>>> y
> [-1, -1, -1]
>>>>
> There's no rational sense in which that can be called call-by-value. A
> similar program using C structs shows what call-by-value does mean:
Let me add a couple lines to your program:
>>> def f(x):
... x[:] = [-1] * 3
>>> y = [1, 2, 3]
>>> id(y)
135466204
>>> f(y)
>>> y
[-1, -1, -1]
>>> id(y)
135466204
The variable y holds the same value before and after the call to f;
only the list to which y holds a reference has been altered.
Scheme is also a call-by-value language, yet:
=> (define (f x)
(set-car! x -1)
(set-cdr! x '(-1 -1)))
F
=> (define y '(1 2 3))
Y
=> (f y)
#unspecified
=> y
(-1 -1 -1)
Aahz
Doug Quale <qua...@charter.net> wrote:
>
>Python is call-by-value. The values are objects, but the argument
>passing mechanism doesn't say anything about what values are in the
>language.
No, the values are not objects. To the extent that it's call-by-value,
the values are references. That's why so many of us object to using the
phrase call-by-value, because people keep getting the process wrong.
Erik Max Francis
> There's no rational sense in which that can be called call-by-value.
It's call-by-value-where-all-values-are-references, which is awfully
confusing to simply abbreviate as "call-by-value."
--
Erik Max Francis && m...@alcyone.com && http://www.alcyone.com/max/
__ San Jose, CA, USA && 37 20 N 121 53 W && &tSftDotIotE
/ \ Perfect girl / She was never me
\__/ Lamya
Tim Peters
> Let me add a couple lines to your program:
>
> >>> def f(x):
> ... x[:] = [-1] * 3
> >>> y = [1, 2, 3]
> >>> id(y)
> 135466204
> >>> f(y)
> >>> y
> [-1, -1, -1]
> >>> id(y)
> 135466204
>
> The variable y holds the same value before and after the call to f;
In Python we say y is bound to the same object, and do not say it holds the
same value. You can say whatever you like when discussing some other
language, but it doesn't help to insist on using a different language's
terminology quirks here.
> only the list to which y holds a reference has been altered.
That's a pretty big "only" <wink>.
> Scheme is also a call-by-value language,
According to who? You're not going to find that phrase in the Scheme
standard, although I realize that the functional programming community often
uses "call by value", and "call by name" or "call by need", to distinguish
between "eager" and "lazy" argument evaluation, respectively. I prefer to
use the plain "eager" and "lazy" for that purpose (although in some contexts
"applicative order" and "normal order" are more natural).
> => (define (f x)
> (set-car! x -1)
> (set-cdr! x '(-1 -1)))
> F
> => (define y '(1 2 3))
> Y
> => (f y)
> #unspecified
> => y
> (-1 -1 -1)
Obviously I don't call that call-by-value. In a Scheme newsgroup I'd let it
pass without comment because of the above, but it's not helpful terminology
here (nor do I think it would be fruitful to try to convince Schemers that
"call by object" describes what Scheme does in a more useful way <wink>).
One of Python's predecessors was the ABC language, and that *did* have
call-by-value function semantics in the sense used here. That kind of
distinction is important for discussing Python in its own historical context
(which includes Algol, ABC, and Pascal, all of which use call-by-value in
this sense (although Algol's call-by-name gimmick/bug is related to lazy
evaluation), but doesn't include Scheme).
when-in-denmark-speak-english-ly y'rs - tim
Fredrik Lundh
> See
>
> http://wombat.doc.ic.ac.uk/foldoc/foldoc.cgi?call-by-value
>
> What you describe is call-by-value.
It's interesting that you quote FOLDOC, given that FOLDOC doesn't
refer to Python's model as call-by-value, as can be seen in the CLU
entry:
http://wombat.doc.ic.ac.uk/foldoc/foldoc.cgi?CLU
"Arguments are passed by call-by-sharing, similar to
call-by-value, except that the arguments are objects
and can be changed only if they are mutable."
Note the use of the words "similar" and "except".
For a brief description of CLU's object and argument passing models,
see [1]. I think you'll find that it matches Python's model pretty well.
The CLU Reference Manual [2] by Liskov et al says (page 14):
"We call the argument passing technique _call by sharing_,
because the argument objects are shared between the
caller and the called routine. This technique does not
correspond to most traditional argument passing techniques
(it is similar to argument passing in LISP). In particular it
is not call by value because mutations of arguments per-
formed by the called routine will be visible to the caller.
And it is not call by reference because access is not given
to the variables of the caller, but merely to certain objects."
Note the use of "does not" and the repeated use of "it is not".
Let me emphasise:
"IN PARTICULAR IT IS NOT CALL BY VALUE because mutations
of arguments performed by the called routine will be visible to
the caller. And IT IS NOT CALL BY REFERENCE because access
is not given to the variables of the caller, but merely to certain
objects."
CLU was designed in the mid-seventies, and this reference manual
was published in 1979. In other literature, the CLU designers some-
times refer to this model as "call by object" [3], or they carefully
ignore the issue by talking about "objects" instead of values, and
"objects that refer to other objects" instead of references [1], but
I cannot find a single place where they've gone from "in particular
it is not call by value" to "it is call by value".
So what's your excuse for being stuck in the early seventies? ;-)
</F>
1) http://www.cs.berkeley.edu/~jcondit/pl-prelim/liskov77clu.pdf
2) http://www.lcs.mit.edu/publications/pubs/pdf/MIT-LCS-TR-225.pdf
3) http://www.lcs.mit.edu/publications/pubs/pdf/MIT-LCS-TR-561.pdf
Fredrik Lundh
> The only really 100% answer to this question - does Python pass by
> value or by reference - is "No!"
You mean "Mu!", right?
</F>
Daan Hoogland
satisfying answers to my question. I did change my subsribtion to digest though.
On Tue, 13 May 2003, you wrote:
> is passing by reffence possible in python?
>
> I'd like the following code to print
> 1
> instead of
> 2
>
> <file name="D.py">
> def spam(**ni):
> ni["egg"] = 1;
>
> bacon = 2
> spam(egg = bacon)
> print bacon
> </file>
>
> the actual construct is going to return several newly created object, to give a
> reason why.
>
> --
> http://mail.python.org/mailman/listinfo/python-list
Joshua Marshall
> Joshua Marshall wrote:
>> See
>>
>> http://wombat.doc.ic.ac.uk/foldoc/foldoc.cgi?call-by-value
>>
>> What you describe is call-by-value.
> It's interesting that you quote FOLDOC, given that FOLDOC doesn't
> refer to Python's model as call-by-value, as can be seen in the CLU
> entry:
> http://wombat.doc.ic.ac.uk/foldoc/foldoc.cgi?CLU
> "Arguments are passed by call-by-sharing, similar to
> call-by-value, except that the arguments are objects
> and can be changed only if they are mutable."
> Note the use of the words "similar" and "except".
Also interesting that
http://wombat.doc.ic.ac.uk/foldoc/foldoc.cgi?call-by-sharing
is missing. This is the first I've heard of call-by-sharing, but it
doesn't sound different than call-by-value to me. (Take C for
example--pass a pointer to a struct, and you can change its fields.
This is like Python--pass a reference to a list and you can change its
elements.)
FOLDOC was just the first definition I came across when I did a
search. For a good intro to semantics, I sugest
Essentials of Programming Languages
Daniel P. Friedman, Mitchell Wand, Christopher Thomas Haynes
> For a brief description of CLU's object and argument passing models,
> see [1]. I think you'll find that it matches Python's model pretty well.
> The CLU Reference Manual [2] by Liskov et al says (page 14):
> "We call the argument passing technique _call by sharing_,
> because the argument objects are shared between the
> caller and the called routine. This technique does not
> correspond to most traditional argument passing techniques
> (it is similar to argument passing in LISP). In particular it
> is not call by value because mutations of arguments per-
> formed by the called routine will be visible to the caller.
> And it is not call by reference because access is not given
> to the variables of the caller, but merely to certain objects."
> Note the use of "does not" and the repeated use of "it is not".
> Let me emphasise:
> "IN PARTICULAR IT IS NOT CALL BY VALUE because mutations
> of arguments performed by the called routine will be visible to
> the caller. And IT IS NOT CALL BY REFERENCE because access
> is not given to the variables of the caller, but merely to certain
> objects."
I'm not familiar with CLU, but I think this description of Python's
argument-passing semantics is misleading.
Christopher A. Craig
> In article <mailman.1052859920...@python.org>,
> Christopher A. Craig <list-...@ccraig.org> wrote:
> >
> >If you look at
> >http://wombat.doc.ic.ac.uk/foldoc/foldoc.cgi?call-by-value
> >
> >You will see that it also describes Python's calling strategy. Python
> >always passes the address of an argument variable rather than the
> >contents of said variable. That assignment will overwrite that address
> >is not related to the passing strategy.
>
> But reading
> http://wombat.doc.ic.ac.uk/foldoc/foldoc.cgi?call-by-reference
> illustrates why there is confusion and why call-by-value is a poor
> phrase; "value of the argument expression" has no meaning in Python.
I apologize. That's what I meant to say. I think the next paragraph
makes a lot more sense if you use the right link. <.9 wink>
--
Christopher A. Craig <list-...@ccraig.org>
Sitting in a church doesn't make you a Christian any more than sitting in a
garage makes you a car -- Billy Sunday
Fredrik Lundh
> Also interesting that [call-by-sharing] is missing
did you read the "Why is this definition missing?" page?
(the FOLDOC maintainers add links to articles that should be written
some day, and keeps track of how many clicks the links get, so they
can focus on things that people really want to read about)
> For a good intro to semantics, I sugest
>
> Essentials of Programming Languages
> Daniel P. Friedman, Mitchell Wand, Christopher Thomas Haynes
if all you have is scheme, etc.
> I'm not familiar with CLU
I suggest reading reference 3.
http://www.lcs.mit.edu/publications/pubs/pdf/MIT-LCS-TR-561.pdf
CLU is an important milestone in the development of OO languages;
to quote Liskov herself, from the above paper:
"The work on CLU, and other related work such as that on
Alphard, served to crystallize the idea of a data abstraction
and make it precise. As a result, the notion is widely used as
an organizing principle in program design and has become a
cornerstone of modern programming methodology."
if you don't know your history, etc.
> but I think this description of Python's argument-passing
> semantics is misleading.
did you read reference 1?
http://www.cs.berkeley.edu/~jcondit/pl-prelim/liskov77clu.pdf
in case your PDF reader is broken, here are the relevant portions from
that document (any typos etc added by me).
"The basic elements of CLU semantics are _objects_ and
_variables_. Objects are the data entities that are created and
manipulated by CLU programs. Variables are just the names used
in a program to refer to objects.
In CLU, each object has a particular _type_, which characterizes
its behavior. A type defines a set of operations that create
and manipulate objects of that type. An object may be created
and manipulated only via the operations of its type.
An object may _refer_ to objects. For example, a record object
refers to the objects that are the components of the record.
This notion is one of logical, not physical, containment. In
particular, it is possible for two distinct record objects to
refer to (or _share_) the same component object. In the case of
a cyclic structure, it is even possible for an object to
"contain" itself. Thus it is possible to have recursive data
structure definitions and shared data objects without explicit
reference types. /.../
CLU objects exist independently of procedure activations. Space
for objects is allocated from a dynamic storage area /.../ In
theory, all objects continue to exist forever. In practice, the
space used by an object may be reclaimed when the object isno
longer accessible to any CLU program.
An object may exhibit time-varying behavior. Such an object,
called a _mutable_ object, has a state which may be modified by
certain operations without changing the identity of the
object. /.../
If a mutable object _m_ is shared by two other objects _x_ and
_y_, then a modification to _m_ made via _x_ wil be visible when
_m_ is examined via _y_. /.../
Objects that do not exhibit time-varying behavior are called
_immutable_ objects, or constants. Examples of constants are
integers, booleans, characters, and strings. The value of a
constant object can not be modified. For example, new strings
may be computed from old ones, but existing strings do not
change. Similarily, none of the integer operations modify the
integers passed to them as arguments.
Variables are names used in CLU programs to _denote_ particular
objects at execution time. Unlike variables in many common
programming languages, which _are_ objects that _contain_
values, CLU variables are simply names that the programmer uses
to refer to objects. As such, it is possible for two variables
to denote (or _share_) the same object. CLU variables are much
like those in LISP and are similar to pointer variables in other
languages. However, CLU variables are _not_ objects; they
cannot be denoted by other variables or referred to by
objects. /.../
The basic actions in CLU are _assignment_ and _procedure
invocation_. The assignment primitive 'x := E' where _x_ is a
variable and _E_ is an expression, causes _x_ to denote the
object resulting from the evaulation of _E_. For example, if
_E_ is a simple variable _y_, then the assignment 'x := y'
causes _x_ to denote the object denoted by _y_. The object is
_not_ copied, it will be _shared_ by _x_ and _y_. Assignment
does not affect the state of any object. (Recall that 'r.s :=
v' is not a true assignment, but an abbreviation for 'put.s(r,
v)'.)
Procedure invocation involves passing argument objects from the
caller to the called procedure and returning result objects from
the procedure to the caller. The formal arguments of a
procedure are considered to be local variables of the procedure
and are initialized, by assignment, to the objects resulting
from the evaluation of the argument expressions. Thus argument
objects are shared between the caller and the called procedure.
A procedure may modify mutable argument objects (e.g. records),
but of course it cannot modify immutable ones (e.g. integers).
A procedure has no access to the variables of its caller.
Procedure invocations may be used directly as statements; those
that return objects may also be used as expressions. Arbitrary
recursive procedures are permitted."
replace "CLU" with "Python", "record" with "instance", and "procedure"
with "function or method", and you get a pretty accurate description
of Python's object model.
if you don't agree, please tell us what Python does differently. be very
specific.
</F>
Terry Reedy
"Fredrik Lundh" <fre...@pythonware.com> wrote in message
news:mailman.1052920226...@python.org...
> did you read reference 1?
>
> http://www.cs.berkeley.edu/~jcondit/pl-prelim/liskov77clu.pdf
>
> in case your PDF reader is broken, here are the relevant portions
from
> that document (any typos etc added by me).
>
> "The basic elements of CLU semantics are _objects_ and
> _variables_. Objects are the data entities that are created and
> manipulated by CLU programs. Variables are just the names used
> in a program to refer to objects.
<etc. rest of excellent extract>
Thanks for extracting this Fredrik. With Python substituted for CLU
(and the other substitutions you mentioned), this is one of the
clearest descriptions of Python semantics I have seen (in over 6
years). Anyone not crystal clear on Python's data model should save
this and reread periodically.
Terry J. Reedy
Tim Peters
description of call-by-object/call-by-sharing, in particular being
careful to distinguish it from call-by-value and call-by-reference
]
> ...
> So what's your excuse for being stuck in the early seventies? ;-)
"call by value" is very often used in the Scheme world to mean "applicative
order evaluation" aka "eager evaluation", which the Scheme standard mandates
(as opposed to lazy evaulation schemes, such as Haskell's call-by-need).
The Scheme standard itself didn't introduce this abuse of terminology, but
it's catchy if it's a distinction you need to make often; in the functional
language world, it is a distinction that needs to be made often. So it
goes -- believe it or not, sometimes different people mean different things
by the same words <wink>. The business of warping "call by value" to mean
"the internal address of the object is the value" doesn't seem common even
in the functional world, though.
Fredrik Lundh
> So it goes -- believe it or not, sometimes different people mean different
> things by the same words <wink>.
that's why you should use URLs and URLs only to identify concepts.
> The business of warping "call by value" to mean "the internal address of
> the object is the value" doesn't seem common even in the functional world,
> though.
well, I guess you can, in theory, value an artificial number assigned
to an object as much as the object itself.
"Joe, I think our son might be lost in the woods"
"Don't worry, I have his social security number"
</F>
Martin Chilvers
> well, I guess you can, in theory, value an artificial number
> assigned to an object as much as the object itself.
I'm not disagreeing with the argument against the 'call by value'
terminology, but I think the above statement is somewhat misleading! The
'artificial number' is obviously not valuable, but the notion of an
'object reference' *is*. I don't care how the system locates objects, I
just care that I have an object that lets me do just that.
Martin Chilvers, Enthought Inc.
"There's no such thing as free software."
Joshua Marshall
>> For a good intro to semantics, I sugest
>>
>> Essentials of Programming Languages
>> Daniel P. Friedman, Mitchell Wand, Christopher Thomas Haynes
> if all you have is scheme, etc.
Scheme is used for examples, but I find this book to be useful in
describing concepts common to many programming languages.
Joshua Marshall
...
> did you read reference 1?
> http://www.cs.berkeley.edu/~jcondit/pl-prelim/liskov77clu.pdf
<snip>
> replace "CLU" with "Python", "record" with "instance", and "procedure"
> with "function or method", and you get a pretty accurate description
> of Python's object model.
> if you don't agree, please tell us what Python does differently. be very
> specific.
Yes, I agree this is an accurate description of Python. CLU function
invocation seems to have call-by-value semantics as well (by my
definition and, I believe, the standard definition). And like python,
values are object references.
From "A History of CLU":
In fact, CLU procedures do not share variables at all. In addition
to there being no free variables, there is no call-by-reference.
Instead arguments are passed "by object"; the (pointer to the) object
resulting from evaluating the actual argument expression is assigned
to the formal. (Thus passing a parameter is just doing an assignment
to the formal.)
This exactly describes call-by-values, where the values are object
references. A few lines further down:
A CLU procedure can have side effects only if the argument objects
can be modified (since it cannot access the caller's variables).
That is the objects /themselves/, not the l-values holding references
to them. I don't think we disagree about semantics, only terminology.
I don't think we'll make further progress here.
Joshua Marshall
> [Fredrik Lundh, quotes the CLU reference manual, which has an excellent
> description of call-by-object/call-by-sharing, in particular being
> careful to distinguish it from call-by-value and call-by-reference
> ]
>> ...
>> So what's your excuse for being stuck in the early seventies? ;-)
> "call by value" is very often used in the Scheme world to mean "applicative
> order evaluation" aka "eager evaluation", which the Scheme standard mandates
> (as opposed to lazy evaulation schemes, such as Haskell's call-by-need).
> The Scheme standard itself didn't introduce this abuse of terminology, but
> it's catchy if it's a distinction you need to make often; in the functional
> language world, it is a distinction that needs to be made often.
I agree this is a misuse of the term "call-by-value". There are
certainly langauges which both employ eager evaluation and
call-by-reference (eg. C++ can).
> So it goes -- believe it or not, sometimes different people mean
> different things by the same words <wink>. The business of warping
> "call by value" to mean "the internal address of the object is the
> value" doesn't seem common even in the functional world, though.
It's only here that I disagree with you. I consider Python values
themselves to be object references, which are simply copied/assigned
to the formal parameters upon function invocation.
Where I do agree with you is that it's an implementation detail that
these object references are implemented as C pointers. For example,
(in a 32-bit world) small integers could be stored in the first 29
bits of a word, leaving three tag-bits to be used as a discriminant
(depending on the value of the discriminant, the first 29 bits might
represent an integer, an 8-byte aligned pointer, a 3-byte string, an
index into a repository of objects, or whatever you'd like).
Ok, enjoyable conversation, but I think we're starting to retread old
ground.
Aahz
Joshua Marshall <joshway_wi...@myway.com> wrote:
>
>I don't think we disagree about semantics, only terminology.
Terminology *is* about semantics, to a certain extent; if we don't have
shared vocabulary, we can't communicate meaning.
>I don't think we'll make further progress here.
Probably not.
Fredrik Lundh
> >I don't think we disagree about semantics, only terminology.
>
> Terminology *is* about semantics, to a certain extent; if we don't have
> shared vocabulary, we can't communicate meaning.
no, but everyone can be 100% right all the time ;-)
(and who cares about what a bunch of renowned computer scientists came
up with some 30 years ago; nobody's using CLU anyway these days...)
</F>
Daniel Fackrell
news:ba0hrt$495$2...@ginger.mathworks.com...
> Fredrik Lundh <fre...@pythonware.com> wrote:
> ...
> > did you read reference 1?
>
> > http://www.cs.berkeley.edu/~jcondit/pl-prelim/liskov77clu.pdf
>
> <snip>
>
> > replace "CLU" with "Python", "record" with "instance", and "procedure"
> > with "function or method", and you get a pretty accurate description
> > of Python's object model.
>
> > if you don't agree, please tell us what Python does differently. be
very
> > specific.
>
> Yes, I agree this is an accurate description of Python. CLU function
> invocation seems to have call-by-value semantics as well (by my
> definition and, I believe, the standard definition). And like python,
> values are object references.
At the machine level, all that can ever be passed to a
procedure/function/method/whatever is a value, so in a sense, all languages
could be considered to be strictly call-by-value.
However, using such a line of thought causes call-by-value to lose all
meaning, as you can no longer distinguish between the methodologies by which
the passed items are used.
It is one thing to use the value directly, another to treat the value as a
pointer to another value, yet another to treat it as a pointer to some
complex structure, and another to treat it as a pointer to an object.
So while you can be considered to be correct in one sense, I don't see that
such correctness lends itself very well to usefulness.
--
Daniel Fackrell (newsgrou...@dfackrell.mailshell.com)
When we attempt the impossible, we can experience true growth.
Doug Quale
> In article <87of267...@charter.net>,
> Doug Quale <qua...@charter.net> wrote:
> >
> >Python is call-by-value. The values are objects, but the argument
> >passing mechanism doesn't say anything about what values are in the
> >language.
>
> No, the values are not objects. To the extent that it's call-by-value,
> the values are references. That's why so many of us object to using the
> phrase call-by-value, because people keep getting the process wrong.
> --
> Aahz (aa...@pythoncraft.com) <*> http://www.pythoncraft.com/
You're right -- I slipped. I should have said the values are
references to objects.
Joshua Marshall
...
>> Yes, I agree this is an accurate description of Python. CLU function
>> invocation seems to have call-by-value semantics as well (by my
>> definition and, I believe, the standard definition). And like python,
>> values are object references.
> At the machine level, all that can ever be passed to a
> procedure/function/method/whatever is a value, so in a sense, all languages
> could be considered to be strictly call-by-value.
No, this is not what I was implying. The difference between
call-by-value and other argument-passing schemes is entirely semantic.
For example, the difference between call-by-value and
call-by-reference can be seen by doing an assignment to a formal
parameter. In a call-by-reference world, this can rebind a variable
in your caller's scope, in a call-by-value world, this does not.
Call-by-reference is often implemented by passing a pointer behind the
scenes.
Daniel Fackrell
In Python, however, a callable can directly change objects in the caller's
scope as a consequence of passing. This can happen e.g. when a list l is
passed and the callable executes l.append(). In a call-by-value world, what
is passed to the callable is strictly a copy. Nothing about it gives any
information which can be used to modify the argument that was passed.
Consider:
>>> def append(l, item):
... l.append(item)
...
>>> l = [1, 2, 3]
>>> l
[1, 2, 3]
>>> append(l, 4)
>>> l
[1, 2, 3, 4]
How can this be explained by call-by-value?
As pointed out by (I believe) Fredrik Lundh and Tim Peters, the traditional
uses of the terms call-by-value and call-by-reference both fall short of
describing Python's passing scheme in important ways.
Luckily, as has also been said, we are not confined to these two terms. As
CLU's passing model is (as far as I can tell from the small amount I've read
about it) identical to that used in Python, it seems to make sense to use
the terms that were invented for the purpose of describing CLU's passing
model, namely call-by-sharing and call-by-object.
Joshua Marshall
...
>>>> def f(x):
> ... x[:] = [-1] * 3
>>>> y = [1, 2, 3]
>>>> f(y)
>>>> y
> [-1, -1, -1]
>>>>
> There's no rational sense in which that can be called call-by-value.
I just noticed something. From
http://python.org/doc/current/tut/node6.html
In section 4.6:
The actual parameters (arguments) to a function call are introduced in
the local symbol table of the called function when it is called; thus,
arguments are passed using call by value (where the value is always an
object reference, not the value of the object). 4.1 When a function
calls another function, a new local symbol table is created for that
call.
And a footnote:
4.1 Actually, call by object reference would be a better
description, since if a mutable object is passed, the caller will
see any changes the callee makes to it (items inserted into a list).
I personally still think using "call by object reference" can be
misleading, but the tutorial does say Python uses call-by-value.
If Guido agrees with you, maybe this should be changed.
Joshua Marshall
...
> Consider:
>>>> def append(l, item):
> ... l.append(item)
> ...
>>>> l = [1, 2, 3]
>>>> l
> [1, 2, 3]
>>>> append(l, 4)
>>>> l
> [1, 2, 3, 4]
> How can this be explained by call-by-value?
A reference is traversed--the object at the end of it is modified. A
variable in the caller's scope also refers to this object, and
therefore sees the change at the end of its own reference.
> As pointed out by (I believe) Fredrik Lundh and Tim Peters, the traditional
> uses of the terms call-by-value and call-by-reference both fall short of
> describing Python's passing scheme in important ways.
We disagree, but that's fine. In fact the original poster has said
he's gotten some valuable information from this discussion, so maybe
we've even done some good.
Doug Quale
> [Doug Quale]
> > Python is call-by-value. The values are objects, but the argument
> > passing mechanism doesn't say anything about what values are in the
> > language.
>
> Sorry, that didn't make sense.
You're right. I meant the values are references to objects. I
apologize, that was a bad slip.
> It's true that, in CPython, pointers to
> objects are passed under the covers, in C's call-by-value fashion, but
> that's an implementation detail, and has no visible effect on the Python
> language's semantics. Call-by-object really is the best description of
> Python's semantics. If you do a literature search, you'll also see that
> described as "call by object reference" and "call by sharing".
> Call-by-value it ain't -- unless you view the implementation reference as
> "the value", but that simply isn't helpful to anyone except Python's
> implementors (of which Jeremy and I are two, BTW).
>
> >>> def f(x):
> ... x[:] = [-1] * 3
> >>> y = [1, 2, 3]
> >>> f(y)
> >>> y
> [-1, -1, -1]
> >>>
>
> There's no rational sense in which that can be called call-by-value.
No, that's exactly what call-by-value means when applied to Python values
(actually r-values). What happens when you try this:
>>> y = [1, 2, 3]
>>> x = y
>>> x[:] = [-1]*3
>>> y
[-1, -1, -1]
Same behavior, no function calls. This behavior occurs because of the
nature of Python values, not because of anything interesting or unusual
about the argument passing mechanism.
Call-by-value has nothing to do with the implementation and everything
to do with the observed behavior. (I know you're a Python
implementor, but you're still wrong about this.)
"Call-by-value
This is, in a sense, the simplest possible method of passing
parameters. The actual parameters are evaluated and their r-values
are passed to the called procedure." (Compilers: Principles, Techniques
and Tools by Aho, Sethi and Ullman).
In order to make sense of the argument passing mechanism you have to
know what a value is in the language. Actually you have to know what
an r-value is in the language, since there are two types of values in
programming languages, l-values and r-values. These terms just refer
to values used on the left and right sides of an assignment. The
value of interest in argument passing is the r-value. Your Python
code is a good example of both l-value and r-value. It appears that
r-values in Python are always object references. (If this is not the
case then I'm sure you can correct me.) Python l-values are more
complex. Often they are names that are bound or rebound to the
r-value, as in
y = [1, 2, 3]
foo.x = 42
Some Python l-values are more easily considered as representing
locations rather than names, such as your example x[:] in
x[:] = [1] * 3
(There might be ways that you could consider x[:] to be a name rather
than locations, but that seems much more complex.) (In most
programming languages descended from the Algol family tree l-values
are most easily thought of as locations that are stored to. In many
other languages like Scheme and the functional programming languages
l-values are better thought of as names that are bound.)
If the value passed to a function is the same value that would be used
on the right hand side of an assignment, the language is
call-by-value. Now you see the rational way in which Python is called
cbv. It really is that simple.
> A similar program using C structs shows what call-by-value does mean:
>
> #include <stdio.h>
>
> struct s {
> int x, y, z;
> };
>
> void display(const char* tag, struct s s) {
> printf("%s %d %d %d\n", tag, s.x, s.y, s.z);
> }
>
> void f(struct s s) {
> display("inside before", s);
> s.x = s.y = s.z = -1;
> display("inside after", s);
> }
>
> void main() {
> struct s t = {1, 2, 3};
> display("before", t);
> f(t);
> display("after", t);
> }
>
> Of course that displays:
>
> before 1 2 3
> inside before 1 2 3
> inside after -1 -1 -1
> after 1 2 3
Yes, and yet here you injure your own argument again. Naturally you
are correct: C is call-by-value. If we used arrays instead of
structs, everyone knows what would happen:
#include <stdio.h>
void display(const char* tag, int s[]) {
printf("%s %d %d %d\n", tag, s[0], s[1], s[2]);
}
void f(int s[]) {
display("inside before", s);
s[0] = s[1] = s[2] = -1;
display("inside after", s);
}
void main() {
int t[] = {1, 2, 3};
display("before", t);
f(t);
display("after", t);
}
Of course that displays
before 1 2 3
inside before 1 2 3
inside after -1 -1 -1
after -1 -1 -1
Why are arrays different? You and I both just said that C was call by
value. Well, C is call by value. The r-value of a C struct is the
struct, but the r-value of a C array is a reference to the first
element in the array.
Some people might explain it by saying that in C, scalars and
structures are passed by value and arrays are passed by reference.
Not only would that be needlessly complex, it would be wrong. C array
r-values are references, and pass-by-reference would then require that
a reference to a reference be passed and that's not what happens. C
arrays are passed in exactly the same way that they are assigned. In
fact every C value is passed in exactly the same way that it is
assigned. That's why C is call-by-value. Python is the same.
Values in Pascal and Python are much simpler than in C because C
r-values are somewhat confusing. (In particular, arrays and structs
are treated differently in C for no apparent reason. Of course it was
a historical accident.) Python r-values are references to objects.
Some Python objects are mutable and some are immutable. Python
argument passing is call-by-value.
The odd thing is that I'm sure that you and Aahz both know all this.
Anyone who understands how assignment works in Python already
understands how argument passing works. That's the true nature of
call-by-value. Trying to say it's something else just means that you
have to explain the same things all over again when you describe how
assignment works. In Python, if you say
y = [1, 2, 3]
x = y
is an assignment of the value of y to x (or better binds the name x to
the value of y), then
f(y)
passes the value of y to f(). This is call-by-value.
Andrew Dalke
> that's why you should use URLs and URLs only to identify concepts.
http://www.dalkescientific.com/I/completely/agree/with/that/statement/
Andrew
Doug Quale
> [Joshua Marshall]
>
> > Scheme is also a call-by-value language,
>
> According to who? You're not going to find that phrase in the Scheme
> standard, although I realize that the functional programming community often
> uses "call by value", and "call by name" or "call by need", to distinguish
> between "eager" and "lazy" argument evaluation, respectively. I prefer to
> use the plain "eager" and "lazy" for that purpose (although in some contexts
> "applicative order" and "normal order" are more natural).
According to Joshua, me and R5RS. R5RS says
"When the procedure is later called with some actual
arguments, the environment in which the lambda expression was evaluated will
be extended by binding the variables in the formal argument list to
fresh locations, the corresponding actual argument values will be stored
in those locations, and the expressions in the body of the lambda expression
will be evaluated sequentially in the extended environment."
That's call-by-value by definition. (All we need is the middle part
about actual argument values being stored in those locations.)
> > => (define (f x)
> > (set-car! x -1)
> > (set-cdr! x '(-1 -1)))
> > F
> > => (define y '(1 2 3))
> > Y
> > => (f y)
> > #unspecified
> > => y
> > (-1 -1 -1)
>
> Obviously I don't call that call-by-value.
Then you are wrong. I have no idea why you don't call that
call-by-value. Either you don't know what cbv means or you are
confused about what r-values are in Scheme. Maybe you should explain
what call-by-value means to you so that we can understand where it
differs from the correct definition.
> (define y '(1 2 3))
> (define x y)
> (set-car! x -1)
> (set-cdr! x '(-1 -1))
> y
(-1 -1 -1)
> In a Scheme newsgroup I'd let it pass without comment because of the above
You are wise.
More wise than me. I should have let this pass in this newsgroup, but
I was mildly annoyed when Aahz repeatedly told Joshua that he was
wrong when Joshua correctly pointed out that Python is call-by-value.
Even Guido's Python Tutorial correctly states that Python is cbv.
Doug Quale
> At the machine level, all that can ever be passed to a
> procedure/function/method/whatever is a value, so in a sense, all languages
> could be considered to be strictly call-by-value.
This isn't really a problem because that's not what call-by-value
means. The term doesn't describe implementation, it describes
behavior. You don't determine whether a programming language is cbv
by looking at its compilers and interpreters, you look at the behavior
of its programs.
In cbv, the parameters are evaluated and their r-values are passed to
the function. That's all there is to it.
Aahz
Doug Quale <qua...@charter.net> wrote:
>
>In cbv, the parameters are evaluated and their r-values are passed to
>the function. That's all there is to it.
Then by that definition, Python is not call-by-value. That's all there
is to it.
--
Aahz (aa...@pythoncraft.com) <*> http://www.pythoncraft.com/
"In many ways, it's a dull language, borrowing solid old concepts from
Doug Quale
> The CLU Reference Manual [2] by Liskov et al says (page 14):
>
> "We call the argument passing technique _call by sharing_,
> because the argument objects are shared between the
> caller and the called routine. This technique does not
> correspond to most traditional argument passing techniques
> (it is similar to argument passing in LISP). In particular it
> is not call by value because mutations of arguments per-
> formed by the called routine will be visible to the caller.
> And it is not call by reference because access is not given
> to the variables of the caller, but merely to certain objects."
>
> Note the use of "does not" and the repeated use of "it is not".
> Let me emphasise:
>
> "IN PARTICULAR IT IS NOT CALL BY VALUE because mutations
> of arguments performed by the called routine will be visible to
> the caller. And IT IS NOT CALL BY REFERENCE because access
> is not given to the variables of the caller, but merely to certain
> objects."
I don't know CLU but I suspect that CLU was/is call-by-value. The
statement about mutations of arguments and cbv is striking -- it's
just plain wrong. This is a remarkably powerful misconception.
C array arguments can be mutated and yet C is pure call-by-value.
Barbara Liskov is a smart person and an important programming language
researcher (one of the early pioneers of OOP), but saying that CLU is
similar to Lisp and yet claiming CLU is not cbv is a contradiction.
This is just an error.
The terms "call-by-sharing" and "call-by-object-reference" are fine,
but they aren't particularly popular in the programming language
research community. I suspect this is because they don't really say
anything -- they both describe call-by-value.
If you say that Python is call-by-object-reference, then you would
also have to say that Python is assignment (or binding) by object
reference, because the value of x inside f() in
def f(x):
x[:] = [-1] * 3
y = [1, 2, 3]
f(y)
is exactly the same as if x were bound directly, as in
y = [1, 2, 3]
x = y
x[:] = [-1] * 3
That's OK, but it's much simpler and saner to just say that Python
binding and function calls work the same way. In both cases the
r-values are object references. When looking at the Python statement
x = y
I say that x is bound to the value of y (and the value of y is a
reference to some object), not x is bound to a reference to the value
of y. If you choose to say "reference to the value of y" then values
will never appear in any description of Python -- everything will be
references to values. This is silly. The values are object
references, and everything follows smoothly.
Using a name different from cbv is necessary when function parameters
are bound differently than they are by an assignment statement. This
happens in Fortran (call-by-reference), Algol (call-by-name), etc. It
doesn't appear to happen with call-by-sharing or call-by-value.
Erik Max Francis
> void main() {
main returns int.
> Why are arrays different? You and I both just said that C was call by
> value. Well, C is call by value. The r-value of a C struct is the
> struct, but the r-value of a C array is a reference to the first
> element in the array.
More basic than that. An array as an argument to a function call is
treated precisely as if it were written as a pointer. So when you
declare a function taking an array, you're really declaring a function
taking a pointer. (You can even test this with sizeof; it will return
the size of the _pointer_, not the declared array.)
So you're not passing a reference to the first element, you're passing a
pointer by value. (And if what you were passing on the calling side was
an array, you're just taking advantage of the fact that an array name
decays to a pointer to the first element.)
> Some people might explain it by saying that in C, scalars and
> structures are passed by value and arrays are passed by reference.
Structures are passed by value; if you have a struct as an argument, a
copy is made.
--
Erik Max Francis && m...@alcyone.com && http://www.alcyone.com/max/
__ San Jose, CA, USA && 37 20 N 121 53 W && &tSftDotIotE
/ \ Life is not a spectacle or a feast; it is a predicament.
\__/ George Santayana
Doug Quale
> Tim Peters wrote:
>
> > There's no rational sense in which that can be called call-by-value.
>
> It's call-by-value-where-all-values-are-references, which is awfully
> confusing to simply abbreviate as "call-by-value."
It is call-by-value-where-all-values-are-references. (Describing
argument passing semantics doesn't describe the nature of values in
the language, so simply call-by-value suffices.) I don't agree that
it's awfully confusing, although clearly I am wrong considering how
much confusion we've seen in this thread.
How do you explain assignment (binding) in Python? The values there
are references too, right?
Fredrik Lundh
> No, that's exactly what call-by-value means when applied to Python values
> (actually r-values). What happens when you try this:
>
> >>> y = [1, 2, 3]
> >>> x = y
> >>> x[:] = [-1]*3
> >>> y
> [-1, -1, -1]
>
> Same behavior, no function calls.
except that "x[:] =" *is* a method call.
x[:] = [-1]*3 passes a slice object and the result of ([-1]*3) to
the x.__setitem__ method, using the standard calling mechanism
(that's what the "the object is asked" stuff in the language ref
means)
"x.y =" is also a method call (__setattr__).
so is "x[y] =" (__setitem__, again).
however, "x = y" isn't.
(and thirty years ago, CLU also had syntactic sugar that looked
like assignments for the uninformed observer, but really was yet
another way to call a procedure. nothing new here.)
</F>
Brian Quinlan
> statement about mutations of arguments and cbv is striking -- it's
> just plain wrong. This is a remarkably powerful misconception.
> C array arguments can be mutated and yet C is pure call-by-value.
I think that you are being overly dogmatic. All argument passing can be
labeled as call-by-value because, at some level, it must be i.e. my
compiler generates the same code for:
void f(int *) and
void f(int &)
The real question is, without thinking about implementation, what call
type best describes Python method calls? One of my CS textbooks has the
following definition:
"""(CBV) An evaluation strategy where arguments are evaluated
before the function or procedure is entered. Only the values
of the arguments are passed and changes to the arguments
within the called procedure have no effect on the actual
arguments as seen by the caller."""
That certainly does not explain the behavior of Python calls.
Cheers,
Brian
Fredrik Lundh
> According to Joshua, me and R5RS. R5RS says
>
> "When the procedure is later called with some actual
> arguments, the environment in which the lambda expression was evaluated will
> be extended by binding the variables in the formal argument list to
> fresh locations, the corresponding actual argument values will be stored
> in those locations, and the expressions in the body of the lambda expression
> will be evaluated sequentially in the extended environment."
>
> That's call-by-value by definition.
but that's not how Python works.
in Python, the variables in the formal argument list are bound to the
actual argument objects. the objects are _shared_ between caller
and callee; there are no "fresh locations" or extra "stores" involved.
(which, of course, is why the CLU folks called this mechanism "call-
by-sharing". and they were real computer scientists, working for a
real computer science laboratory ;-)
and btw, Python functions doesn't run in an extended environment,
either. function bodies have very limited access to the surrounding
environment. but that's another story.
</F>
Terry Reedy
> It's only here that I disagree with you. I consider Python values
> themselves to be object references, which are simply copied/assigned
> to the formal parameters upon function invocation.
To me and, I believe, most pythoneers, the value of an int object is
its integer value: ..., -1, 0, 1, ... . The value of a string object
is its sequence of bytes. A 'reference' to a Python object is *not* a
Python object. It is whatever a non-godly interpreter, human or
machine, needs to associate (non-object) names and container object
slots with Python objects.
> Where I do agree with you is that it's an implementation detail that
> these object references are implemented as C pointers.
Only in the C-coded interpreter. The Java-coded interpreter does
something else. No one seems to know quite how we humans associate
name with objects or if 'reference' will be part of some future
description.
> Ok, enjoyable conversation, but I think we're starting to retread
old
> ground.
So let me inject a somewhat different thought. C, for example, is
pretty explicitly a language for computer execution: variables are
sized blocks of memory with integer addresses subject to addition and
subtraction. (I am aware of the Intel exception, and of non-standard
kludges like 'near' and 'far'.) Python is a more general algorithm
language defined in terms of names, typed information units (objects),
undefined, interpreter-implemented, 'associations' between the two,
and operations on the information values. It is optimized more for
human interpretation than execution speed, but, unlike algorithm
pseudocodes, is also machine interpretable. That's why I dubbed it
'executable pseudocode' over 6 years ago. (The semi-oxymoronic irony
was intentional). While some may not like this viewpoint, others like
me find it useful, which is what viewpoints are about.
Terry J. Reedy
Terry Reedy
"Doug Quale" <qua...@charter.net> wrote in message
news:87n0hog...@charter.net...
> You're right. I meant the values are references to objects.
"reference to object" is an implementation concept and method, but not
a 'value' in the abstract universe defined by Python, the information
algorithm language. Python the language is not (C)Python, the
standard C-coded machine implementation. Your statement is true, or
can be reasonably seen to be so, in reference to the C implementation,
but it is not necessarily even very meaningful from a more abstract
viewpoint. So if we are talking in different contexts, it is not
surprising we evaluate the statement differently.
Terry J. Reedy
Doug Quale
> Joshua Marshall wrote:
>
> > For a good intro to semantics, I sugest
> >
> > Essentials of Programming Languages
> > Daniel P. Friedman, Mitchell Wand, Christopher Thomas Haynes
>
> if all you have is scheme, etc.
It's a good reference to programming languages in general. The
authors are prominent researchers in the field. Scheme provides a
good basis for discussing many programming language concepts, although
its syntax doesn't demonstrate very much about issues involved in
parsing. From the description you give below CLU doesn't offer much
more.
> in case your PDF reader is broken, here are the relevant portions from
> that document (any typos etc added by me).
>
> "The basic elements of CLU semantics are _objects_ and
> _variables_. Objects are the data entities that are created and
> manipulated by CLU programs. Variables are just the names used
> in a program to refer to objects.
Same as Scheme and Lisp.
> In CLU, each object has a particular _type_, which characterizes
> its behavior. A type defines a set of operations that create
> and manipulate objects of that type. An object may be created
> and manipulated only via the operations of its type.
Same as Scheme and Lisp. Types are associated with objects (values),
not variables. This is strong dynamic (or latent) typing. (CLU might
be statically typed since you can't tell from these excerpts, but I
suspect that it is dynamically typed.)
> An object may _refer_ to objects. For example, a record object
> refers to the objects that are the components of the record.
> This notion is one of logical, not physical, containment. In
> particular, it is possible for two distinct record objects to
> refer to (or _share_) the same component object. In the case of
> a cyclic structure, it is even possible for an object to
> "contain" itself. Thus it is possible to have recursive data
> structure definitions and shared data objects without explicit
> reference types. /.../
Same as Scheme and Lisp.
> CLU objects exist independently of procedure activations. Space
> for objects is allocated from a dynamic storage area /.../ In
> theory, all objects continue to exist forever. In practice, the
> space used by an object may be reclaimed when the object isno
> longer accessible to any CLU program.
Indefinite extent + garbage collection, same as Scheme and Lisp.
> An object may exhibit time-varying behavior. Such an object,
> called a _mutable_ object, has a state which may be modified by
> certain operations without changing the identity of the
> object. /.../
> If a mutable object _m_ is shared by two other objects _x_ and
> _y_, then a modification to _m_ made via _x_ wil be visible when
> _m_ is examined via _y_. /.../
Same as Scheme and Lisp. Note that in pure functional languages all
values are immutable. Scheme and Lisp are not pure.
>
> Objects that do not exhibit time-varying behavior are called
> _immutable_ objects, or constants. Examples of constants are
> integers, booleans, characters, and strings. The value of a
> constant object can not be modified. For example, new strings
> may be computed from old ones, but existing strings do not
> change. Similarily, none of the integer operations modify the
> integers passed to them as arguments.
Same as Scheme and Lisp except that strings are mutable in those languages.
> Variables are names used in CLU programs to _denote_ particular
> objects at execution time. Unlike variables in many common
> programming languages, which _are_ objects that _contain_
> values, CLU variables are simply names that the programmer uses
> to refer to objects. As such, it is possible for two variables
> to denote (or _share_) the same object. CLU variables are much
> like those in LISP and are similar to pointer variables in other
> languages. However, CLU variables are _not_ objects; they
> cannot be denoted by other variables or referred to by
> objects. /.../
Same as Scheme and Lisp. Same as C treatment of arrays and pointer
values.
> The basic actions in CLU are _assignment_ and _procedure
> invocation_. The assignment primitive 'x := E' where _x_ is a
> variable and _E_ is an expression, causes _x_ to denote the
> object resulting from the evaulation of _E_. For example, if
> _E_ is a simple variable _y_, then the assignment 'x := y'
> causes _x_ to denote the object denoted by _y_. The object is
> _not_ copied, it will be _shared_ by _x_ and _y_. Assignment
> does not affect the state of any object. (Recall that 'r.s :=
> v' is not a true assignment, but an abbreviation for 'put.s(r,
> v)'.)
Same as Scheme and Lisp, although naturally the syntax is different.
Scheme uses (define x E) and (set! x E) for assignment. Lisp uses
(setq x E).
> Procedure invocation involves passing argument objects from the
> caller to the called procedure and returning result objects from
> the procedure to the caller. The formal arguments of a
> procedure are considered to be local variables of the procedure
> and are initialized, by assignment, to the objects resulting
> from the evaluation of the argument expressions. Thus argument
> objects are shared between the caller and the called procedure.
> A procedure may modify mutable argument objects (e.g. records),
> but of course it cannot modify immutable ones (e.g. integers).
> A procedure has no access to the variables of its caller.
This is a description of call-by-value using CLU values (object
references). Note that CLU values used in variable assignment and the
binding done by argument passing are the same. This is the key point.
> Procedure invocations may be used directly as statements; those
> that return objects may also be used as expressions. Arbitrary
> recursive procedures are permitted."
>
> replace "CLU" with "Python", "record" with "instance", and "procedure"
> with "function or method", and you get a pretty accurate description
> of Python's object model.
>
> if you don't agree, please tell us what Python does differently. be very
> specific.
It describes Python very well. Since it also describes a
call-by-value argument passing semantics, one can conclude that CLU
and Python, like Scheme and Lisp, are call-by-value.
If you don't agree that this describes call-by-value argument passing,
tell us what Python does differently. Be very specific.
Erik Max Francis
> I think that you are being overly dogmatic. All argument passing can
> be
> labeled as call-by-value because, at some level, it must be i.e. my
> compiler generates the same code for:
>
> void f(int *) and
> void f(int &)
But saying this all boils down to call-by-value misses the point.
Distinctions between call-by-value and call-by-reference aren't about
the _implementation_, they're about the high-level behavior of the
language.
Python as a language is closer to call-by-reference than call-by-value,
but it's really best described as something in between or different,
since "references" in Python are bindings and don't have the same kind
of long-lasting meaning that they do in, say, C++.
--
Erik Max Francis && m...@alcyone.com && http://www.alcyone.com/max/
__ San Jose, CA, USA && 37 20 N 121 53 W && &tSftDotIotE
/ \ My life was better before I knew you.
\__/ Edith Wharton (to Morton Fullerton)
Fredrik Lundh
> In section 4.6:
>
> The actual parameters (arguments) to a function call are introduced in
> the local symbol table of the called function when it is called; thus,
> arguments are passed using _call by value_ (where the _value_ is always
> an object reference, not the value of the object).
it's a trick ;-)
if you read that sentence carefully, with the original emphasis left intact,
you'll notice that he says that python uses "_call by value_ where _value_
is not the value of the [argument]".
which clearly isn't the _call-by-value_ that FOLDOC talks about when they
say that "Only the values of the arguments are passed"...
</F>
Fredrik Lundh
> It's only here that I disagree with you. I consider Python values
> themselves to be object references
if you keep inventing your own terminology, you'll never win this
argument:
http://www.python.org/doc/current/ref/objects.html
"Objects, values and types"
_Objects_ are Python's abstraction for data. All data in a
Python program is represented by objects or by relations
between objects.
Every object has an identity, a type and a value. An object's
_identity_ never changes once it has been created; you may
think of it as the object's address in memory. /.../ An object's
_type_ is also unchangeable. It determines the operations that
an object supports (e.g., ``does it have a length?'') and also
defines the possible values for objects of that type. /.../ The
_value_ of some objects can change. Objects whose value can
change are said to be _mutable_; objects whose value is un-
changeable once they are created are called _immutable_.
(this is basically the same terminology as in the CLU papers, except
that they used the term "state" instead of Python's "value")
...so I guess what you've been saying all the time is that Python
uses call-by-identity, not call-by-state. fair enough.
</F>
Joshua Marshall
> Joshua Marshall wrote:
>> It's only here that I disagree with you. I consider Python values
>> themselves to be object references
> if you keep inventing your own terminology, you'll never win this
> argument:
I've quoted it elsewhere in the thread, but I'll do it again here. From
http://python.org/doc/current/tut/node6.html
section 4.6:
The actual parameters (arguments) to a function call are introduced
in the local symbol table of the called function when it is called;
thus, arguments are passed using call by value (where the value is
always an object reference, not the value of the object).
Is "object reference" the term you claim I made up?
> http://www.python.org/doc/current/ref/objects.html
> "Objects, values and types"
> _Objects_ are Python's abstraction for data. All data in a
> Python program is represented by objects or by relations
> between objects.
The documentation is a little schizophrenic about "objects" versus
"object references", but this isn't a problem, since Python has no
dereferencing operator.
Donn Cave
| "Fredrik Lundh" <fre...@pythonware.com> writes:
... [ quoting account of CLU system (by Barbara Liskov?) ]
...
|> Objects that do not exhibit time-varying behavior are called
|> _immutable_ objects, or constants. Examples of constants are
|> integers, booleans, characters, and strings. The value of a
|> constant object can not be modified. For example, new strings
|> may be computed from old ones, but existing strings do not
|> change. Similarily, none of the integer operations modify the
|> integers passed to them as arguments.
|
| Same as Scheme and Lisp except that strings are mutable in those languages.
What does ``the value of a constant object cannot be modified'' mean?
Is it possible that by "value", the author means the computer data
represented by the object?
| This is a description of call-by-value using CLU values (object
| references). Note that CLU values used in variable assignment and the
| binding done by argument passing are the same. This is the key point.
Does this key point require that we always expect "value" in the
context of CLU to mean "object reference"? Or would you agree that
this would actually be absurd, except in the context of "call-by-value"
where we know it must have that meaning because Python passes object
references, Python is like Scheme and Scheme is call-by-value?
Donn Cave, do...@u.washington.edu
Fredrik Lundh
> This is a description of call-by-value using CLU values (object
> references).
so? if, in doug-speak, object references are the same thing as
values, that's also a description of call-by-object-reference.
is your point that you can redefine words to make them mean
whatever you want? I think we've already noticed that...
</F>
Brian Quinlan
> But saying this all boils down to call-by-value misses the point.
> Distinctions between call-by-value and call-by-reference aren't about
> the _implementation_, they're about the high-level behavior of the
> language.
-1, Redundant
Cheers,
Brian
Tim Peters
> ...
> I should have let this pass in this newsgroup, but I was mildly annoyed
> when Aahz repeatedly told Joshua that he was wrong when Joshua correctly
> pointed out that Python is call-by-value. Even Guido's Python Tutorial
> correctly states that Python is cbv.
And corrected it with a footnote because, as you haven't yet picked up,
calling Python cbv isn't *helpful*. I'll repeat a msg from 2 years ago:
http://mail.python.org/pipermail/python-list/2001-June/048702.html
I usually say Python does "call by object". Then people go "hmm,
what's that?". If you say "call by XXX" instead, then the inevitable
outcome is a tedious demonstration that it's not what *they* mean by
XXX. Instead I get to hear impassioned arguments that "by object"
is what any normal person means by YYY <wink>.
I'll note now that you (and Joshua, and so far) fit into the last sentence
of that, with YYY == "call by value". You're not the first <wink>.
BTW, I believe Barbara Liskov first coined "call by object" to
describe argument-passing in CLU.
A primary difference between you and Joshua and responders (including me,
Aahz, Jeremy, Fredrik and Terry), is that we've been explaining Python to
newcomers for many years. The idea that "call by value" has One True
Objective Meaning is simply silly, as actually doing the literature search I
suggested at the start would have shown you. It's used to mean several
distinct things, depending on the programming culture using it. Even so, in
no case does it have enough explanatory power to answer most practical
questions about the semantics of calls in Python. Therefore it's useless as
a pedagogical device here. In contrast, Liskov's description of "call by
object reference" explains just about everything, and applies almost
verbatim to CLU, Smalltalk, Python, and-- with a little bit of squinting to
exempt special forms and macro calls --a majority of Lisp variants.
So I don't care what you (or Joshua) want to insist "call by value" means --
no matter what it means to you, it doesn't *help* here. If you care to
learn something new, I recommend Henry Baker's "Equal Rights for Functional
Objects", which argues the issue in detail in the context of Lisp:
http://home.pipeline.com/~hbaker1/ObjectIdentity.html
I'll just quote the start of section 7 ("Call-by-reference versus
call-by-value") here:
Despite the thirty years that the problem of "call-by-reference"
versus "call-by-value" in argument-passing semantics of Algol-like
programming languages has been discussed, it has never been clearly
resolved. While many undergraduate texts [Aho86,s.7.5] and language
manuals give a definition of each policy, there has always been a
nagging feeling that these definitions for Algol-60, Fortran and Ada
are too ad hoc and too implementation-oriented.
...
We claim that the only argument-passing model that is consistent
in non-functional languages is call-by-object-reference, i.e.,
passing object identities.
He goes on to explain why it's incorrect to call Lisp "call-by-value", and I
agree -- provided that by "call-by-value", you mean the One True Objective
Meaning it had when I was your age <wink -- I'm afraid it had several
meanings then too, and that's only gotten worse, the most recent abuse being
the widespread adoption (in one sub-culture) of using cbv to mean
applicative-order evaluation>.
If thinking of Python as being cbv helps you to understand it, I certainly
don't object to that. The evidence of the last decade is that it actively
hinders understanding for most newcomers, but that explaining call-by-object
actively helps.
stick-around-and-you'll-eventually-agree-ly y'rs - tim
Tim Peters
> ...
> If you don't agree that this describes call-by-value argument passing,
> tell us what Python does differently. Be very specific.
See Henry Baker's paper (referenced earlier;
http://home.pipeline.com/~hbaker1/ObjectIdentity.html
) for why a venerable Lisp expert believes "call by value" is incorrect even
for describing Lisp -- but he doesn't mean the same thing by "call by value"
that you mean. That alone doesn't mean he's wrong either <wink>.
Doug Quale
> The real question is, without thinking about implementation, what call
> type best describes Python method calls? One of my CS textbooks has the
> following definition:
>
> """(CBV) An evaluation strategy where arguments are evaluated
> before the function or procedure is entered. Only the values
> of the arguments are passed and changes to the arguments
> within the called procedure have no effect on the actual
> arguments as seen by the caller."""
>
> That certainly does not explain the behavior of Python calls.
Your CS textbook is wrong -- what is the name of the book?
Very precise definition of call-by-value would require denotational
semantics (Stoy, Reynolds, etc.) which is out of my league.
Fortunately this idea really isn't that hard so we can take a more
informal view.
"Compilers: Principles, Techniques and Tools" by Aho, Sethi and Ullman
"Call-by-Value
This is, in a sense, the simplest possible method of passing
parameters. The actual parameters are evaluated and their r-values
are passed to the called procedure. Call-by-value is used in C, and
Pascal parameters are usually passed this way."
Call-by-value isn't about implementation, it's about behavior. It
explains the behavior of Python calls. If you think that it doesn't,
then demonstrate a Python function call that doesn't get passed the
r-values of its parameters.
In Tim Peter's example,
>>> def f(x):
>>> x[:] = [-1] * 3
>>>
>>> y = [1, 2, 3]
>>> id(y)
135448932
>>> f(y)
>>> y
[-1, -1, -1]
>>> id(y)
135448932
the variable (name) y is bound to a list object. List objects are
mutable in Python. During the call f(y), the local name x is bound to
the same object as y. After the call f(y), the name y is still bound
to the *same* object. The call f(y) mutated that object, but y's
binding has *not* changed. This in itself doesn't make Python
call-by-value, but it doesn't rule out c-b-v either. C arrays behave
in exactly the same way and C is c-b-v. In order to apply the
definition of c-b-v to Python we need to know what Python r-values
are. The r-value is used when you assign directly:
>>> y = [1, 2, 3]
>>> id(y)
135448932
>>> x = y
>>> id(x)
135448932
>>> x[:] = [-1] * 3
>>> y
[-1, -1, -1]
>>> id(x)
135448932
>>> id(y)
135448932
Same behavior. You can see that Python functions are passed r-values
(the values used for the right sides of assignments). Other calling
mechanisms such as call-by-reference, call-by-name and
call-by-copy-in-out do not behave this way.
The Pythonistas' meme about what call-by-value is would indicate that
C and Java are not call-by-value. (In fact only pure functional
languages would qualify, and there's already good terminology to
describe them -- "pure functional language".) This is incorrect, as
can be seen by applying the correct definition of c-b-v. It seems
that people are making this too complex by thinking that c-b-v means
more than it really does.
Doug Quale
> Doug Quale wrote:
>
> > No, that's exactly what call-by-value means when applied to Python values
> > (actually r-values). What happens when you try this:
> >
> > >>> y = [1, 2, 3]
> > >>> x = y
> > >>> x[:] = [-1]*3
> > >>> y
> > [-1, -1, -1]
> >
> > Same behavior, no function calls.
>
> except that "x[:] =" *is* a method call.
It's special syntax. It can be viewed as a special operator on the
surface level and it would behave the same.
Doug Quale
No. Reference is not an implementation concept, it's a semantic
concept and completely abstract. Saying y is a reference to a list
object in
y = [1, 2, 3]
is the same thing as saying that y denotes a list object.
If you think this is not so, explain what a Python value is.
Tim Peters
>>> I consider Python values themselves to be object references
[Fredrik Lundh]
>> if you keep inventing your own terminology, you'll never win this
>> argument:
[Joshua Marshall]
> I've quoted it elsewhere in the thread, but I'll do it again here.
> ...
> Is "object reference" the term you claim I made up?
I don't think so, he was pointing at the Python manual's "Objects, values
and types" section, and the objection is to using a strained (non-Python)
meaning for "value". The referenced section makes clear that, in Python, an
object's value and an object's identity are distinct concepts. Python never
passes values -- not as Python uses the word "value". It always pass object
identities. You can call object identities values if it helps your mental
model, but doing so in public <wink> only confuses the issues for people
using Python's native terminology.
> The documentation is a little schizophrenic about "objects" versus
> "object references", but this isn't a problem, since Python has no
> dereferencing operator.
Right on target.
Joshua Marshall
...
> The idea that "call by value" has One True Objective Meaning is
> simply silly, as actually doing the literature search I suggested at
> the start would have shown you. It's used to mean several distinct
> things, depending on the programming culture using it.
I guess one of the reasons I've continued taking part in this
discussion is that I think it's useful for terminology to be clear and
unambiguous; and I'm pushing toward that goal. But I no longer think
that's likely (at least for these terms in this group of people).
Doug Quale
> [Doug Quale]
> > ...
> > I should have let this pass in this newsgroup, but I was mildly annoyed
> > when Aahz repeatedly told Joshua that he was wrong when Joshua correctly
> > pointed out that Python is call-by-value. Even Guido's Python Tutorial
> > correctly states that Python is cbv.
>
> And corrected it with a footnote because, as you haven't yet picked up,
> calling Python cbv isn't *helpful*. I'll repeat a msg from 2 years ago:
>
> http://mail.python.org/pipermail/python-list/2001-June/048702.html
>
> I usually say Python does "call by object". Then people go "hmm,
> what's that?". If you say "call by XXX" instead, then the inevitable
> outcome is a tedious demonstration that it's not what *they* mean by
> XXX. Instead I get to hear impassioned arguments that "by object"
> is what any normal person means by YYY <wink>.
>
> I'll note now that you (and Joshua, and so far) fit into the last sentence
> of that, with YYY == "call by value". You're not the first <wink>.
(I had looked up some of your earlier posts on this issue after I
entered this morass. Google says that "call-by-object-reference" is
most popular recently in reference to Python, often in threads that
you have participated in in this group. The term is not unknown in
published computer science research, but it's rare.)
I'm afraid I can't determine the meaning of technical terms like
"call-by-value" by what any normal person thinks it means. Like any
specialized technical terminology it means what expert practicioners
in the field agree it means. This is the same in law, medicine,
mathematics, etc. I'm sorry that so many people find this troubling,
but I don't tell a biologist that he's crazy to say that the giant
panda is more closely related to the racoon family than the bear
family just because it's my hobbyist opinion that it's obvious that a
panda is a bear. (I read recently that there is more evidence that
the giant panda is more closely related to the bear than the racoon,
but apparently the issue still isn't settled definitively.)
> BTW, I believe Barbara Liskov first coined "call by object" to
> describe argument-passing in CLU.
>
> A primary difference between you and Joshua and responders (including me,
> Aahz, Jeremy, Fredrik and Terry), is that we've been explaining Python to
> newcomers for many years. The idea that "call by value" has One True
> Objective Meaning is simply silly, as actually doing the literature search I
> suggested at the start would have shown you. It's used to mean several
> distinct things, depending on the programming culture using it. Even so, in
> no case does it have enough explanatory power to answer most practical
> questions about the semantics of calls in Python.
What practical question can it not explain about calls in Python? It
very easily explains the example you gave before.
> Therefore it's useless as
> a pedagogical device here. In contrast, Liskov's description of "call by
> object reference" explains just about everything, and applies almost
> verbatim to CLU, Smalltalk, Python, and-- with a little bit of squinting to
> exempt special forms and macro calls --a majority of Lisp variants.
Argument passing in Java and C are no different from Python. The same
mutation that you showed in your Python example occurs there too. Do
you think that "call by object reference" explains them? Java and C
are both usually considered to be call-by-value, but you seem to have
a different opinion.
> So I don't care what you (or Joshua) want to insist "call by value" means --
> no matter what it means to you, it doesn't *help* here. If you care to
> learn something new, I recommend Henry Baker's "Equal Rights for Functional
> Objects", which argues the issue in detail in the context of Lisp:
>
> http://home.pipeline.com/~hbaker1/ObjectIdentity.html
>
> I'll just quote the start of section 7 ("Call-by-reference versus
> call-by-value") here:
>
> Despite the thirty years that the problem of "call-by-reference"
> versus "call-by-value" in argument-passing semantics of Algol-like
> programming languages has been discussed, it has never been clearly
> resolved. While many undergraduate texts [Aho86,s.7.5] and language
> manuals give a definition of each policy, there has always been a
> nagging feeling that these definitions for Algol-60, Fortran and Ada
> are too ad hoc and too implementation-oriented.
>
> ...
>
> We claim that the only argument-passing model that is consistent
> in non-functional languages is call-by-object-reference, i.e.,
> passing object identities.
>
> He goes on to explain why it's incorrect to call Lisp "call-by-value", and I
> agree -- provided that by "call-by-value", you mean the One True Objective
> Meaning it had when I was your age <wink -- I'm afraid it had several
> meanings then too, and that's only gotten worse, the most recent abuse being
> the widespread adoption (in one sub-culture) of using cbv to mean
> applicative-order evaluation>.
Henry Baker is a very bright guy, but I'm not on the bus with this one.
I didn't just invent a definition for call-by-value based on what I
thought it should mean. I learned the definition at school from
professor Fischer. Professor Fischer researches computer programming
languages, and I presume that he taught his class the definition of
the term as it is used in the field.
Here is what Ravi Sethi says in "Programming Languages: Concepts and
Constructs":
"The effect of a procedure call in a programming language depends on
the answer to the following question:
What is the correspondence between the actual parameters in a
procedure call and the formal parameters in the procedure body?
The answers examined in this section are motivated by differing
interpretations of what a parameter stands for. Does an actual
parameter A[j] in a procedure call P(A[j]) represent its r-value, its
l-value, or the program text A[j] itself? Some interpretations are
* Call-by-value. Pass the r-value of A[j].
* Call-by-reference. Pass the l-value of A[j].
* Call-by-name. Pass the text of A[j] itself, avoiding "name clashes."
Another variant, examined later, is call-by-value-result."
If Python is not call-by-value, what is an r-value in Python that
differs from what is passed to a function? Basically I want you to
explain why Python is not call-by-value by this definition (and the
one used in Aho, Sethi and Ullman which not surprisingly is the same).
If Python is not cbv by this definition then it is clearly not cbv.
In that case, I was wrong, the debate is over. If Python is cbv by
this definition then it's clear that you don't accept this definition.
That's fine, but then it would be helpful to know what your definition
of call-by-value is.
> If thinking of Python as being cbv helps you to understand it, I certainly
> don't object to that. The evidence of the last decade is that it actively
> hinders understanding for most newcomers, but that explaining call-by-object
> actively helps.
I have no objection to calling Python argument passing
call-by-object-reference. (I would be curious to know why you think
that is different from call-by-value in a language like Python where
r-values are object references.) On the other hand, if someone says
Python argument passing is call-by-value I don't recommend telling him
he's wrong as Aahz did what seems like thousands of messages ago.
> stick-around-and-you'll-eventually-agree-ly y'rs - tim
I have to say that your posts always make me smile. comp.lang.python
is a remarkably friendly forum and I apologize to all for a cranky
post or two I made earlier.
Aahz
Doug Quale <qua...@charter.net> wrote:
>
>How do you explain assignment (binding) in Python? The values there
>are references too, right?
Actually, I don't use "value" at all when talking about Python when I
can help it, because there's the confusion with "value of an object".
Doug Quale
Sheesh. I gave an explicit definition of call-by-value.
Aho, Sethi and Ullman, "Compilers: Principles, Techniques and Tools"
"Call by Value
This is, in a sense, the simplest possible method of passing
parameters. The actual parameters are evaluated and their r-values
are passed to the called procedure."
How does this not apply to Python? Be sure to explain what an r-value
is in Python, and how it differs from the values passed to functions.
It looks to me like r-values in Python are object references. What
are they in Fredrik-speak?
Doug Quale
> Doug Quale wrote:
>
> > void main() {
>
> main returns int.
I copied Tim's example making the minimum changes necessary to
demonstrate the point. (His example had void main() also.)
Flame away if it makes you happy.
> > Why are arrays different? You and I both just said that C was call by
> > value. Well, C is call by value. The r-value of a C struct is the
> > struct, but the r-value of a C array is a reference to the first
> > element in the array.
>
> More basic than that. An array as an argument to a function call is
> treated precisely as if it were written as a pointer. So when you
> declare a function taking an array, you're really declaring a function
> taking a pointer. (You can even test this with sizeof; it will return
> the size of the _pointer_, not the declared array.)
>
> So you're not passing a reference to the first element, you're passing a
> pointer by value. (And if what you were passing on the calling side was
> an array, you're just taking advantage of the fact that an array name
> decays to a pointer to the first element.)
That's exactly the point. The r-value of a C array is a pointer. (In
your words, "an array name decays to a pointer to the first element.)
The r-value gets passed; C is call-by-value. C array arguments show
the same behavior as arguments passed in Python.
> > Some people might explain it by saying that in C, scalars and
> > structures are passed by value and arrays are passed by reference.
>
> Structures are passed by value; if you have a struct as an argument, a
> copy is made.
Your point is? I said some people might say structures are passed by
value. Those people are right, since all C arguments are passed by
value.
Doug Quale
> In article <874r3vh...@charter.net>,
> Doug Quale <qua...@charter.net> wrote:
> >
> >How do you explain assignment (binding) in Python? The values there
> >are references too, right?
>
> Actually, I don't use "value" at all when talking about Python when I
> can help it, because there's the confusion with "value of an object".
> --
> Aahz (aa...@pythoncraft.com) <*> http://www.pythoncraft.com/
Right, but I ask that that answer be stricken from the record as
non-responsive. Python binding does need to be explained, even if you
don't like to use the word value. How do you explain it?
Doug Quale
> Quoth Doug Quale <qua...@charter.net>:
> | "Fredrik Lundh" <fre...@pythonware.com> writes:
> ... [ quoting account of CLU system (by Barbara Liskov?) ]
> ...
> |> Objects that do not exhibit time-varying behavior are called
> |> _immutable_ objects, or constants. Examples of constants are
> |> integers, booleans, characters, and strings. The value of a
> |> constant object can not be modified. For example, new strings
> |> may be computed from old ones, but existing strings do not
> |> change. Similarily, none of the integer operations modify the
> |> integers passed to them as arguments.
> |
> | Same as Scheme and Lisp except that strings are mutable in those languages.
>
> What does ``the value of a constant object cannot be modified'' mean?
> Is it possible that by "value", the author means the computer data
> represented by the object?
It means there are no operations that can modify the object. The
object would be modified if any of its observable behavior were
changed. You could have a language with modifiable integer objects,
for instance, but programming with them would be unecessarily
difficult. In most languages all scalar values are immutable. (This
wasn't the case in Fortran where call-by-reference allowed changing
constants with usually undesired effects.) Scalar values are usually
not precisely defined but the basic idea is that the value can't be
decomposed into smaller parts. Often the scalar values in a language
are simply listed.
>
> | This is a description of call-by-value using CLU values (object
> | references). Note that CLU values used in variable assignment and the
> | binding done by argument passing are the same. This is the key point.
>
> Does this key point require that we always expect "value" in the
> context of CLU to mean "object reference"? Or would you agree that
> this would actually be absurd, except in the context of "call-by-value"
> where we know it must have that meaning because Python passes object
> references, Python is like Scheme and Scheme is call-by-value?
No. Value here means r-value. These are the values used on the right
side of assignments or bindings. The concept of l-values and r-values
makes sense for any programming language that has assignment or
binding. Curiously, there are languages that have neither. For
example John Backus' FP doesn't even have variables.
I don't think I understand what people think Python values are. If E
is some Python expression, does it have a different value in a
function call
def f(x):
...
f(E)
than it does in an assignment (binding)
x = E
?
Doug Quale
> Doug Quale wrote:
>
> > According to Joshua, me and R5RS. R5RS says
> >
> > "When the procedure is later called with some actual
> > arguments, the environment in which the lambda expression was evaluated will
> > be extended by binding the variables in the formal argument list to
> > fresh locations, the corresponding actual argument values will be stored
> > in those locations, and the expressions in the body of the lambda expression
> > will be evaluated sequentially in the extended environment."
> >
> > That's call-by-value by definition.
>
> but that's not how Python works.
>
> in Python, the variables in the formal argument list are bound to the
> actual argument objects. the objects are _shared_ between caller
> and callee; there are no "fresh locations" or extra "stores" involved.
No, not really. The actual argument objects you refer to are the
argument values -- the arguments are evaluated before they are passed.
Storing the argument values in those new locations is simply creating
a new binding. In Python,
>>> def fact(n):
>>> if n == 1:
>>> return n
>>> else:
>>> return n * fact(n - 1)
>>>
>>> fact(5)
120
Each call to fact(n) binds a new name (fresh location). If this
weren't the case, recursive calls wouldn't work in Python. Function
calls push stack precisely because fresh locations are used. If no
fresh locations were needed Python wouldn't have to have a recursion
limit.
The stack was invented to make just this thing work in Algol 60 (43
years ago!). (Algol was call-by-name, but that was decided before
they realized that c-b-n is a mistake.)
> (which, of course, is why the CLU folks called this mechanism "call-
> by-sharing". and they were real computer scientists, working for a
> real computer science laboratory ;-)
I think call-by-sharing is unneeded terminology, but that's just my
opinion. I've seen it applied also to Smalltalk, but it doesn't seem
to have gained much traction in the programming language theory
community. I suspect that's because it doesn't mean anything
different than call-by-value for the languages to which it's been
applied.
> and btw, Python functions doesn't run in an extended environment,
> either. function bodies have very limited access to the surrounding
> environment. but that's another story.
True, but that's only because Python closures are lame. ;-) Pascal and
C are even more restrictive than Python, but they are all c-b-v.
Tim Peters
> The idea that "call by value" has One True Objective Meaning is
> simply silly, as actually doing the literature search I suggested at
> the start would have shown you. It's used to mean several distinct
> things, depending on the programming culture using it.
[Joshua Marshall]
> I guess one of the reasons I've continued taking part in this
> discussion is that I think it's useful for terminology to be clear and
> unambiguous; and I'm pushing toward that goal. But I no longer think
> that's likely (at least for these terms in this group of people).
Well, it's not likely with any group of people <wink>. "call by value" in
particular has a history dating back to the 1950s, and the older the term in
an explosively growing field, the more meanings it picks up. That's why I
don't use that specific phrase at all anymore, unless I know my audience
inside-out. It *should* have been clear that Liskov already had this
problem when explaining CLU, and felt compelled to invent a new phrase to
cut off pointless confusion decades ago.
Do read Henry Baker's paper to see that you're not going to find consensus
on this phrase even in the hardcore Lisp community:
http://home.pipeline.com/~hbaker1/ObjectIdentity.html
Lisp is sometimes characterized as "call-by-value", but this is
incorrect. Lisp approximates call-by-object-reference semantics
extremely well, and the single lacuna can be easily repaired. The
reason Lisp appears to be call-by-value is that arguments which are
functional data structures appear to have been passed in toto.
However, it is the nature of functional data structures that
whether they are passed by value or by reference is not
determinable, hence we consider these data structures to have been
passed by "object reference".
"Call-by-value" coerces arguments into their "values", which causes
mutable portions of a structure to be replaced by their current
values; Lisp does not usually do this. ...
This is the meaning of call-by-value that was most prevalent when I was in
college (early 70's). Henry is an old fart too, and it's Nature's Design
that old farts die, so that you can hope to do better. However, I bet
against it <wink>. In the *purely* functional-language subculture,
call-by-value has become synonymous with strict/applicative-order
evaluation. There's plenty of evidence for that in Philip Wadler's (a giant
in that field) recent papers:
http://www.research.avayalabs.com/user/wadler/topics/call-by-need.html
In part this is because (as Baker points out in the quote above) there's no
observable difference between (traditional meanings) call-by-value and
call-by-reference in purely functional languages. So they took a
comfortable phrase and gave it a meaning more useful to their real needs.
There's no confusion about this when they talk among themselves, though!
Indeed, that's part of what being a subculture means. It's not usually
intended to be a barrier to keep others out, although it can come across
that way, and misunderstandings when distinct cultures meet are inevitable.
luckily-almost-everyone-on-earth-is-an-old-white-male<wink>-ly y'rs - tim
Erik Max Francis
> Your point is? I said some people might say structures are passed by
> value. Those people are right, since all C arguments are passed by
> value.
I am correcting your inaccurate comments about another language which
you are attempting to use as an example.
--
Erik Max Francis && m...@alcyone.com && http://www.alcyone.com/max/
__ San Jose, CA, USA && 37 20 N 121 53 W && &tSftDotIotE
/ \ You are inspiration to my life / You are the reason why I smile
\__/ India Arie
Tim Peters
> (I had looked up some of your earlier posts on this issue after I
> entered this morass. Google says that "call-by-object-reference" is
> most popular recently in reference to Python, often in threads that
> you have participated in in this group. The term is not unknown in
> published computer science research, but it's rare.)
Sorry, I didn't mean a literature search on call-by-object-reference, I
meant a literature search on call-by-value. You can't come away from such a
search still believing there's a single "true meaning" for that phrase. Or,
if you can, there's no hope for you <wink>.
Even the FOLDOC definition people started with here:
changes to the arguments within the called procedure have no
effect on the actual arguments as seen by the caller
doesn't match your preferred meaning, except by virtue of extreme
logic-chopping about what "no effect on the actual arguments" means. I'm
afraid I think it's plainly unreasonable to claim that, when I do
x = [1, 2, 3]
f(x)
print x
and see [-1, -1, -1], the f(x) call can be said to "have no effect on the
actual arguments as seen by the caller". To get away with that trick
requires stripping words of all reasonable meaning. BTW, the FOLDOC
definition does match the most widely accepted meaning for call-by-value
from my college days (although there was more than one meaning in common use
then too). I believe the phrase has been "elaborated" so much in succeeding
years that a different meaning is more common now, and the phrase is
correspondingly less useful than it once was.
> I'm afraid I can't determine the meaning of technical terms like
> "call-by-value" by what any normal person thinks it means. Like any
> specialized technical terminology it means what expert practicioners
> in the field agree it means.
And when they don't agree on a single definition? They don't in this case,
but it's not a religious issue to them either, and neither is it a barrier
to communication when the differences are understood.
> This is the same in law, medicine, mathematics, etc. I'm sorry that
> so many people find this troubling, but I don't tell a biologist that
> he's crazy to say that the giant panda is more closely related to the
> racoon family than the bear family just because it's my hobbyist
> opinion that it's obvious that a panda is a bear. (I read recently
> that there is more evidence that the giant panda is more closely
> related to the bear than the racoon, but apparently the issue still
> isn't settled definitively.)
That was fun to read (thanks! btw, it's a bear <wink>), but I don't see the
relevance.
>> Even so, in no case does it have enough explanatory power to answer
>> most practical questions about the semantics of calls in Python.
> What practical question can it not explain about calls in Python? It
> very easily explains the example you gave before.
Actually not: virtually all of the explanation lied in dragging in r-value
and l-value concepts. Occam's Razor is what opposes that: all arguments in
Python are passed by object identity, some objects are mutable, others
aren't, and an explanation built on those terms is *useful* in Python life.
You won't hear about r-values and l-values again in Python, so it's not
helpful here to drag them in. Of course if you were trained to think of
everything in terms or r- and l-values, it would be helpful to you -- but
most people haven't been so trained.
> ...
> Argument passing in Java and C are no different from Python.
Given the meanings you insist that words have, possibly so. It's an easily
observable fact that people coming from C have a hard time learning Python's
calling semantics, though, so that should give you pause about whether
you're constructing a useful model of reality. Python and Java are indeed
close, and people moving from C to Java have a hard time learning Java's
calling semantics too; people moving between Python and Java don't stumble
over this.
> The same mutation that you showed in your Python example occurs there
> too.
It depends on whether a pointer or structure is passed in C. There's no
such distinction in Python.
> Do you think that "call by object reference" explains them?
In Python, yes. C doesn't use call-by-object, so "no" to that part.
> Java and C are both usually considered to be call-by-value, but you
> seem to have a different opinion.
You're not hearing: I'm not arguing for any specific meaning of
call-by-value. I gave up on that futile quest in the 1900s. I understand
that Java is described by its creators as call-by-value, and I understand
what they mean by that. I've never taken a compsci course that mentioned
Java (it was invented long after my college days), but 5 minutes' googling
turned up many sets of university lecture notes on Java. Google's top hit
of that sort is here:
www.d.umn.edu/~rmaclin/cs5641/Notes/Lecture13.pdf
It claims that "everything is call by value" in Java, then trips over itself
with the convoluted "but for objects it's really a copy of a reference"
business, and ends with the incorrect claim that "but the pointer to the
object can then also be changed".
The second hit was:
http://www.cs.wright.edu/people/faculty/rrea/jmethod.html
This one claims:
Java provides both a Call by Value and a Call by Reference capability.
Call by Value means that the value is passed to the method and any
changes to that passed value will NOT change the value in the calling
method. Any primative [sic] variable that is passed such an [sic] an
integer, a float, and so on is automatically passed by value. This
is a safe, but limiting way to pass a parameter.
Call by Reference means that the called method can change the value
in the calling method. If you pass an Object, it is automatically
passed by reference. We will get to objects in the next chapter.
I know what he means too, and expect that his students will come out with a
clearer understanding of how Java actually works.
The third:
http://www.sor.princeton.edu/~rvdb/201/lectures/lec22.pdf
says Java is call-by-value but then does the usual dance exempting objects
from the implications of that, and goes on to say that C/C++ structs are
"the real thing" when it comes to call-by-value. So I suspect that
Professor Vanderbei would be happier if he didn't feel compelled to say that
everything in Java is call-by-value.
A few more down and you get to Philip Wadler's home page (which happens to
mention Java for an irrelevant reason), and you'll crawl on your belly for a
month trying to figure out what *he* means by "call-by-value" <0.9 wink>.
And on it goes, seesawing between lecturers who stick to the
everything-is-call-by-value-in-Java party line then scrambling to explain
that object arguments in Java aren't really copied, and those who ignore the
party line, sticking to the more traditional distinction that primitive
types in Java are passed by value but that class objects and arrays are
passed by reference.
I do believe they would benefit by dropping that whole mess and embracing
call-by-object terminology instead. Short of that, I don't care what they
want to say call-by-value means.
> ...
> Henry Baker is a very bright guy, but I'm not on the bus with this one.
No kidding <wink>.
> I didn't just invent a definition for call-by-value based on what I
> thought it should mean. I learned the definition at school from
> professor Fischer. Professor Fischer researches computer programming
> languages, and I presume that he taught his class the definition of
> the term as it is used in the field.
I'm sure he taught the definition the subculture he belongs to uses most
often. Fine by me. Believing that's the only definition in wide use
remains silly, though. You're also free to believe that only people who
embrace Prof. Fischer's definition in all respects are expert practitioners,
but the world you live in shrinks with each such demand <0.5 wink>. I have
a bold suggestion: ask Prof. Fischer whether *he* believes there's only one
true defintion of this term (BTW, is this Charles Fischer of UW Madison? if
so, I'd say his specialty is more compiler design than language design; and
if you can, get him to argue about this with Baker on some Lisp list
<wink>).
> Here is what Ravi Sethi says in "Programming Languages: Concepts and
> Constructs": ...
Sorry, I'm spacing out on this, and am out of time for this anyway. You
don't need to convince me that many people in the field embrace the
definition you like -- I knew that going into this. It doesn't change that
it's not universally accepted, or that I strongly doubt that any of the
authorities you've been exposed to would claim that this is a matter of One
Objective Truth. Indeed, the dueling quotes game is proof that it isn't.
Unlike biologists arguing over the giant panda, we're not studying physical
reality here -- outside the mathematical foundations of compsci, words are
chosen mostly for perceived utility, and those perceptions vary (for good
reasons) across groups.
> ...
> I have no objection to calling Python argument passing
> call-by-object-reference. (I would be curious to know why you think
> that is different from call-by-value in a language like Python where
> r-values are object references.)
I'm not answering this one again: it's a matter of what's *helpful*, as
I've explained several times already. The mess I found in the Java lecture
notes is typical of what comes from *not* breaking away from these old
overloaded phrases. At heart, saying "call by object" invites exploration,
while saying "call by value" invites confusion. Nobody except a computer
newbie comes to Python without *some* idea of what "call by value" means,
and they really don't have the same ideas. Tedious lectures opposing fixed
ideas are far less productive than approaching it from an angle they don't
have preconceived notions about.
> On the other hand, if someone says Python argument passing is call-by-
> value I don't recommend telling him he's wrong as Aahz did what seems
> like thousands of messages ago.
By the definition he was taught (you're not the only one here to attend a
class <wink>), I expect it is wrong. Then each eventually figures out what
the other meant, and it ends with a group hug <wink>.
> I have to say that your posts always make me smile. comp.lang.python
> is a remarkably friendly forum and I apologize to all for a cranky
> post or two I made earlier.
That's very gracious, and appreciated. Time to write some Python code.
Donn Cave
| "Donn Cave" <do...@u.washington.edu> writes:
[... re quote from CLU document ...]
|> What does ``the value of a constant object cannot be modified'' mean?
|> Is it possible that by "value", the author means the computer data
|> represented by the object?
|
| It means there are no operations that can modify the object. The
| object would be modified if any of its observable behavior were
| changed. You could have a language with modifiable integer objects,
| for instance, but programming with them would be unecessarily
| difficult. In most languages all scalar values are immutable. (This
| wasn't the case in Fortran where call-by-reference allowed changing
| constants with usually undesired effects.) Scalar values are usually
| not precisely defined but the basic idea is that the value can't be
| decomposed into smaller parts. Often the scalar values in a language
| are simply listed.
Could I draw your attention to your use of the word "value" here?
"Scalar values", "observable behavior", etc.
|> | This is a description of call-by-value using CLU values (object
|> | references). Note that CLU values used in variable assignment and the
|> | binding done by argument passing are the same. This is the key point.
|>
|> Does this key point require that we always expect "value" in the
|> context of CLU to mean "object reference"? Or would you agree that
|> this would actually be absurd, except in the context of "call-by-value"
|> where we know it must have that meaning because Python passes object
|> references, Python is like Scheme and Scheme is call-by-value?
|
| No. Value here means r-value. These are the values used on the right
| side of assignments or bindings. The concept of l-values and r-values
| makes sense for any programming language that has assignment or
| binding. Curiously, there are languages that have neither. For
| example John Backus' FP doesn't even have variables.
|
| I don't think I understand what people think Python values are. If E
| is some Python expression, does it have a different value in a
| function call
|
| def f(x):
| ...
|
| f(E)
|
| than it does in an assignment (binding)
|
| x = E
|
| ?
I think people think Python values are the kind of value you were
talking about above, in your account of immutable constants. A
value is the behavior of string-ness or whatever. The language
has a mechanism by which it deploys these values, object reference,
but the mechanism is not the value.
Donn Cave, do...@drizzle.com
David Abrahams
> If Python is not call-by-value, what is an r-value in Python that
> differs from what is passed to a function?
I should probably stay out of this, but...
it doesn't make a whole lot of sense to talk about r-values and
l-values in Python, because those terms are normally defined in terms
of assignment:
"an r-value is something that can appear on the right hand side of
an assignment"
"an l-value is something that can appear on the left hand side of
an assignment"
In Python, the only things that can appear on the LHS of an assignment
are names (not values in any reasonable sense). These terms were
invented to describe languages where assignment causes copying, and
they have analytical power because they distinguish two different
ideas. You can try to view assignment in Python as "copying a
reference" so that the terms apply, but then of course they lose all
power as distinctions: everything is both an l-value and an r-value.
--
Dave Abrahams
Boost Consulting
www.boost-consulting.com
Joshua Marshall
>> If Python is not call-by-value, what is an r-value in Python that
>> differs from what is passed to a function?
> I should probably stay out of this, but...
> it doesn't make a whole lot of sense to talk about r-values and
> l-values in Python, because those terms are normally defined in terms
> of assignment:
> "an r-value is something that can appear on the right hand side of
> an assignment"
> "an l-value is something that can appear on the left hand side of
> an assignment"
> In Python, the only things that can appear on the LHS of an assignment
> are names (not values in any reasonable sense).
This isn't true. Expressions like "X", "(A, B)", and "A[i]" can be
l-values or r-values, depending on the context--whether they're on the
left side of an assignment or not. Expressions like "2", "()", and
"f(1)" can only br r-values (you can't assign to them).
The terms "l-value" and "r-value" apply to any language which has assignment.
Jordan Krushen
Firstly, I'm no expert, but I believe I can help people understand this
conversation better.
> Quoth Doug Quale <qua...@charter.net>:
> | "Fredrik Lundh" <fre...@pythonware.com> writes:
> ... [ quoting account of CLU system (by Barbara Liskov?) ]
> ...
> |> Objects that do not exhibit time-varying behavior are called
> |> _immutable_ objects, or constants. Examples of constants are
> |> integers, booleans, characters, and strings. The value of a
> |> constant object can not be modified. For example, new strings
> |> may be computed from old ones, but existing strings do not
> |> change. Similarily, none of the integer operations modify the
> |> integers passed to them as arguments.
> |
> | Same as Scheme and Lisp except that strings are mutable in those
> languages.
>
> What does ``the value of a constant object cannot be modified'' mean?
> Is it possible that by "value", the author means the computer data
> represented by the object?
The *value* of a *variable* is an object.
The *value* of an *object* is the above 'computer data'
Variables can be modified (rebound) -- they can reference new objects
Immutable *objects* are, in fact, immutable -- their contents (computer
data) cannot be changed.
Several variables can reference the same *object* (ie have the same
*value*)
This explains the following well-known idiom:
>>> l1 = [1,2,3] # assigns [1,2,3] to an object, assigns that object to l1
>>> l2 = l1 # assigns above list object to l2 as well
>>> l1[1] = 'ni' # modifies object's value (computer data)
>>> l1 # l1's *value* is still the list object
[1, 'ni', 3] # this displays the *object's* value
>>> l2 # l2's *value* is still the list object
[1, 'ni', 3] # this displays the *same object's* value
One would argue that the *value* of both l1 and l2 is the same object. If
one were to now write id(l1) and id(l2), they would be identical (at least
they are to me). The *value* of that *object* is [1, 'ni', 3].
I think most of the problem here stems from the fact that when assigns
'computer data' ([1,2,3]) to 'l1', one doesn't necessarily see that it's a
two-step process -- object creation, and object binding.
I don't think anyone would disagree that calling f(x) passes the object
bound by x to f(). Ignoring under-the-hood implementation, this is how it
effectively gets used by the Python programmer. The problem is the
semantic difference -- that the 'object bound by x' is seen by many to be a
pointer of sorts, and thereby a reference. The catch is that the 'object
bound by x' is the same thing as the 'value of x'. The 'value of the value
of x' would be the actual computer data.
People seem to forget that a variable is a reference to a reference of
actual data. There's an object in the middle, which is the rvalue of x.
This *value* gets passed to functions, which, under-the-hood, expand it to
determine the actual 'computer data' held within.
Am I correct in understanding that this is why Doug is calling it CBV, and
others are calling it CBR? The fact that f(x) does not send a reference to
x, but the value of x, which is itself a reference of sorts?
J.
Mel Wilson
Doug Quale <qua...@charter.net> wrote:
>Tim Peters <tim...@comcast.net> writes:
>> [ ... ] Even so, in
>> no case does it [call-by-value] have enough explanatory power to answer most practical
>> questions about the semantics of calls in Python.
>
>What practical question can it not explain about calls in Python? It
>very easily explains the example you gave before.
It can't explain how a function call
a_function (a_thing)
can have the semantics of call-by-value if a_thing is immutable,
but call-by-reference if a_thing is mutable.
Regards. Mel.
Aahz
Doug Quale <qua...@charter.net> wrote:
>
>If you don't agree that this describes call-by-value argument passing,
>tell us what Python does differently. Be very specific.
All right, you explain this:
>>> x = 'foo'
>>> '%s' % (x,)
What gets printed by the %s?
--
Aahz (aa...@pythoncraft.com) <*> http://www.pythoncraft.com/
"In many ways, it's a dull language, borrowing solid old concepts from
Aahz
Doug Quale <qua...@charter.net> wrote:
>aa...@pythoncraft.com (Aahz) writes:
>> In article <874r3vh...@charter.net>,
>> Doug Quale <qua...@charter.net> wrote:
>>>
>>>How do you explain assignment (binding) in Python? The values there
>>>are references too, right?
>>
>> Actually, I don't use "value" at all when talking about Python when I
>> can help it, because there's the confusion with "value of an object".
>
>non-responsive. Python binding does need to be explained, even if you
>don't like to use the word value. How do you explain it?
Here's what I usually say:
In Python, names contain bindings to objects. A binding is a
reference, but experienced Python programmers do not use "reference"
because references are not accessible within Python programs (unlike
pointers in C).
--
Aahz (aa...@pythoncraft.com) <*> http://www.pythoncraft.com/
"In many ways, it's a dull language, borrowing solid old concepts from
Aahz
Doug Quale <qua...@charter.net> wrote:
>
>Argument passing in Java and C are no different from Python.
At the technical level, that's correct, provided you define "argument"
correctly. But because assignment does different things in Python, too
many Java/C programmers get confused with Python's semantics.
In C, you have this:
myStruct a, b;
a.x = 1;
b = a;
a.x = 2;
print ("%d\n", b.x);
There's simply nowhere in Python that assignment performs a value copy
that way. Using "value" to describe both the references to objects and
to the objects themselves is too confusing. Therefore "call-by-value"
is confusing and should be avoided when discussing Python.
Joshua Marshall
> In article <873cjfb...@charter.net>,
> Doug Quale <qua...@charter.net> wrote:
>>
>>Argument passing in Java and C are no different from Python.
> At the technical level, that's correct, provided you define "argument"
> correctly. But because assignment does different things in Python, too
> many Java/C programmers get confused with Python's semantics.
> In C, you have this:
> myStruct a, b;
> a.x = 1;
> b = a;
> a.x = 2;
> print ("%d\n", b.x);
> There's simply nowhere in Python that assignment performs a value copy
> that way. Using "value" to describe both the references to objects and
> to the objects themselves is too confusing. Therefore "call-by-value"
> is confusing and should be avoided when discussing Python.
I think you're just going to have to accept that there are those who
disagree with you.
Donn Cave
|> ... Python binding does need to be explained, even if you
|> don't like to use the word value. How do you explain it?
|
| Here's what I usually say:
|
| In Python, names contain bindings to objects. A binding is a
| reference, but experienced Python programmers do not use "reference"
| because references are not accessible within Python programs (unlike
| pointers in C).
Hm. On one hand, it seems to me that reference is quite commonly used
by people who probably think of themselves as experienced Python
programmers. Some of it you might excuse as a legacy, like "reference
count" or "circular reference", but you'll also read things like
"what I was hoping for is to store the reference (not the value) of ..."
and "that b is actually a reference to the ..."
On the other hand, I don't get the reasoning either. Are bindings
accessible within Python programs?
Reference continues to be the technical term for this mechanism, binding
is a popular informal term. Most effective explanations use both terms,
as yours does but without the curious deprecation. That's my take.
Donn Cave, do...@u.washington.edu
Donn Cave
| Aahz <aa...@pythoncraft.com> wrote:
... [re C example]
|> There's simply nowhere in Python that assignment performs a value copy
|> that way. Using "value" to describe both the references to objects and
|> to the objects themselves is too confusing. Therefore "call-by-value"
|> is confusing and should be avoided when discussing Python.
|
| I think you're just going to have to accept that there are those who
| disagree with you.
He also has to point out that they're wrong, that's what's awkward
about it.
Any number of people here can explain how Python works in a jiffy,
it's quite simple. After two days of wrangling over it, we have to
consider the possibility that call by value is indeed confusing when
applied to Python, and that by itself - especially without exotic
definitions of "value" - it does not explain how Python works.
If that's how you want it, you can evidently arrive at an internally
consistent terminology where call by value does apply to Python, and
in that respect we can just agree to disagree - it's not where my head
is at, but apparently it works for you.
But here in comp.lang.python, it is wrong to introduce this term in
the attempt to be helpful, because it isn't helpful, it's confusing
and it should be avoided for that reason.
Donn Cave, do...@u.washington.edu
Aahz
Donn Cave <do...@u.washington.edu> wrote:
>
>On the other hand, I don't get the reasoning either. Are bindings
>accessible within Python programs?
Nope. That's why I think "binding" is better than "reference".
Donn Cave
| In article <ba3b8s$22ng$1...@nntp6.u.washington.edu>,
| Donn Cave <do...@u.washington.edu> wrote:
|> On the other hand, I don't get the reasoning either. Are bindings
|> accessible within Python programs?
|
| Nope. That's why I think "binding" is better than "reference".
OK, I don't need to pursue that, just want to point out that if
you're making a case for this terminology, it is as clear as mud
to earthbound intellects like mine.
Donn Cave, do...@u.washington.edu