Call By Object
“When I use a word, Humpty Dumpty said, in a rather scornful tone, it means just what I choose it to mean, neither more nor less.
The question is, said Alice, whether you can make words mean so many different things.
The question is, said Humpty Dumpty, which is to be master — that’s all.”
From time to time, people who’ve read a little CS but not a lot CS (or too much of just one kind of CS) pop up on comp.lang.python and waste a lot of energy trying to tell everyone that Python’s using some calling model that it doesn’t really use. It always turns out that they don’t really understand Python’s model, and quite often, they don’t understand their favourite model either.
But nevermind, the only thing you need to know is that Python’s model is neither “call by value” nor “call by reference” (because any attempt to use those terms for Python requires you to use non-standard definitions of the words “-value” and “-reference”). The most accurate description is CLU’s “call by object” or “call by sharing“. Or, if you prefer, “call by object reference“.
You should also read this, if you haven’t done so already.
The following excerpts are taken from an old comp.lang.python thread. The interesting parts are the CLU texts, which provide a very concise description of Python’s calling model.
(Some day, I’ll turn this into a proper article…)
Date: Wed, 14 May 2003 08:48:08 +0200 > 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 . I think you'll find that it matches Python's model pretty well. The CLU Reference Manual  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" , or they carefully ignore the issue by talking about "objects" instead of values, and "objects that refer to other objects" instead of references , 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
Date: Wed, 14 May 2003 15:49:09 +0200 > 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>
Date: Thu, 15 May 2003 15:55:57 +0200 Tim Peters wrote: > 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>
Date: Thu, 15 May 2003 23:11:53 +0200 > 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>
Date: Thu, 15 May 2003 23:39:30 +0200 > 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>
Date: Fri, 16 May 2003 00:25:45 +0200 > 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>
Date: Fri, 16 May 2003 01:05:37 +0200 > 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>