Finding the instance reference of an object

On Sat, 08 Nov 2008 18:31:47 +1300, greg wrote:

Marc 'BlackJack' Rintsch wrote:

>You have said the value that is copied is a pointer to the object.

This assumes that "call by value" means "call by copying the value".

That assumption is WRONG.

Not according to my Comp Sci lecturers back in the day, and not according
to my Pascal books.

E.g. "Programming In Pascal", 2nd Edition (1985), by Peter Grogono of
Concordia University refers to "value" parameters and "variable"
parameters to refer to the standard Pascal call-by-value convention and
the call-by-reference convention you get when you declare a parameter
with the var keyword. He writes:

"When an object is passed to a procedure by value, a local copy of it is
made. If the object is a large array, the copying operation will make the
program slower and will increase its memory requirements."

This was written as an undergraduate textbook. Remember that in 1985, OOP
was far more exotic than now, and object in the above means any Pascal
type (integer, array, set etc.) and not object as we understand it today.

Grogono doesn't explicitly use the terms "call-by-value" and "call-by-
reference", but my lecture notes from the time make it clear that the
Melbourne University Comp Sci department understood those terms to imply
Pascal calling semantics.

It doesn't mean that. It means "call by ASSIGNING the value."

Which, in languages like Pascal, means COPYING the value. And that leads
to confusion when people who understand C-B-V to mean what Pascal means
by the term hear that Python is C-B-V.

So, you can think of the value of an expression as being an object, as
opposed to a reference to an object, if you want.

That's the natural interpretation based on the ordinary meaning of the
word "value". In a language like Python that doesn't have references,
it's the only sensible interpretation. Otherwise you're forced to argue
that following a statement x=1, the value of x is something that has no
existence in Python code.

But then you need to
consider what it means to assign that value to a name.

But you need to do that anyway.

Here's a simple C program:

struct Rec
{
int x;
};

struct Rec a;
struct Rec b;

int main(void)
{
a.x = 1;
b = a;
printf("Before: %d %d\n", a.x, b.x);
a.x += 1;
printf("After: %d %d\n", a.x, b.x);
return 0;
}
It prints:

Before: 1 1
After: 2 1

Here's a simple Python equivalent:

class Rec:
pass

a = Rec()
a.x = 1
b = a
print "Before: %d %d" % (a.x, b.x)
a.x += 1
print "After: %d %d" % (a.x, b.x)

It prints:
Before: 1 1
After: 2 2

Anyone want to argue that assignment in Python is the same as in C?

Obviously it doesn't mean copying the value -- it must mean making the
name refer to the value somehow.

There's no "obviously" about it. To anyone who has learned that "call-by-
value" means that a copy is made, "obviously" it does mean copying the
value. If you have learned a different meaning, then you will believe
differently.

The same thing happens when the value is passed to a function.

Sure. Calling conventions in Python are the same as name/value binding,
except that you have a slight extra complication due to having two
namespaces instead of one.

--
Steven

Nov 8 '08 #153

On Sat, 08 Nov 2008 19:30:17 +1300, greg wrote:

Something has just occurred to me. If you take the view that the value
of an expression is an object, then the terms "value" and "object" are
synonymous.

So far so good.

So if you then insist that Python uses "call by object", you're actually
saying it uses call by value!

Fail!

The terms "guy" and "man" are synonymous, but a wise guy and a wise man
are not.

--
Steven

Nov 8 '08 #154

Joe Strout

On Nov 7, 2008, at 6:21 PM, Aaron Brady wrote:

Therefore objects don't need names to exist. Having a name is
sufficient but not necessary to exist. Being in a container is
neither necessary -nor- sufficient.

What do you mean? Being in a container isn't necessary, but it
certainly is sufficient.

Having ANY references to it is both necessary and sufficient to
exist. And isn't that the easiest way to say it?

Best,
- Joe

Nov 8 '08 #155

On Nov 8, 8:42*am, Joe Strout <j...@strout.netwrote:

On Nov 7, 2008, at 6:21 PM, Aaron Brady wrote:

Therefore objects don't need names to exist. *Having a name is
sufficient but not necessary to exist. *Being in a container is
neither necessary -nor- sufficient.

What do you mean? *Being in a container isn't necessary, but it *
certainly is sufficient.

Having ANY references to it is both necessary and sufficient to *
exist. *And isn't that the easiest way to say it?

No, you forgot about cyclically-linked garbage, which Python
implementations are allowed to, but not required to, collect.

Nov 8 '08 #156

On Nov 8, 1:08*am, Steven D'Aprano <st...@REMOVE-THIS-
cybersource.com.auwrote:

On Sat, 08 Nov 2008 18:31:47 +1300, greg wrote:

There's no "obviously" about it. To anyone who has learned that "call-by-
value" means that a copy is made, "obviously" it does mean copying the
value. If you have learned a different meaning, then you will believe
differently.

I don't think it's obvious to everyone what a copy constructor is and
when it's called. That's ok, it's something you can learn. I think
Joe's idea is that you can think of every variable in Python as a
pointer, and that clears up some confusions about its variable model.
What happens when a pointer is copied? What is an example of copying
a pointer in spoken language?

>>a= [ 1, 2, 3 ]

Are the following true?

The value of 'a' is an object.
The value of that object is [ 1, 2, 3 ].
The value of 'a' is [ 1, 2, 3 ].

If so, 'value' is ambiguous and therefore not very useful as a term.

Nov 8 '08 #157

Steven D'Aprano wrote:

In an attempt to keep this post from hitting the ridiculous length of one

(Aside: I've learned one thing in this discussion. Despite the number of
sources I've read that claim that if you pass an array to a C function
the entire array will be copied, this does not appear to be true....)

Since C does not have an array type, it is impossible to pass an array.
int *a, b[10] declares *both* a and b as int pointers. As I remember,
the only difference is that b is initialized to the address of an
allocated block of 10. In expressions, b is an int pointer, just like
a, and a[i] and b[i] are defined the same, as *(a+i) and *(b+i), where
the addition is pointer arithmetic. Function definitions can only define
parameters as pointers (and lots else), not arrays. So passing either a
or b passes the address it represents. (Function names also represent
addresses in expressions, whereas, I believe, in C99 at least, struct
names represent the struc, not its address.)

tjr

Nov 8 '08 #158

Grant Edwards

On 2008-11-08, Terry Reedy <tj*****@udel.eduwrote:

Steven D'Aprano wrote:
>In an attempt to keep this post from hitting the ridiculous length of one

>(Aside: I've learned one thing in this discussion. Despite the number of
sources I've read that claim that if you pass an array to a C function
the entire array will be copied, this does not appear to be true....)

Since C does not have an array type, it is impossible to pass an array.
int *a, b[10] declares *both* a and b as int pointers. As I remember,
the only difference is that b is initialized to the address of an
allocated block of 10.

No, that's not true. "b" is not a pointer that's initialized
with an address. "b" is a constant literal that is equivalent
to the address of the first element in the "array". IOW,
(void*)b == (void*)&b == (void*)&b[0].

That's not true for a. (void*)a == (void*)&a[0],
but (void*)a != (void*)&a.

In expressions, b is an int pointer, just like a, and a[i] and
b[i] are defined the same, as *(a+i) and *(b+i), where the
addition is pointer arithmetic.

True, but &a and &b are very different, and "a" can be used as
an lvalue and "b" can not. "a" is a variable, and "b" is a
literal constant (that can, for static storage classes, be
resolved to a value at compile/load time).

Function definitions can only define parameters as pointers
(and lots else), not arrays. So passing either a or b passes
the address it represents. (Function names also represent
addresses in expressions, whereas, I believe, in C99 at least,
struct names represent the struc, not its address.)

--
Grant

Nov 9 '08 #159

On Nov 8, 10:59*pm, Joe Strout <j...@strout.netwrote:

Of course, I've softened my position somewhat, since being shown that *
"call by sharing" is simply a term for call-by-value in the case where *
the values are object references. *That clearly does apply to Python *
(as well as other OOP languages, where object references are *
involved), and as long as we can explain it as just a restricted form *
of call-by-value, I'm OK with that.

Humor me briefly. In 'x= [1, 2, 3]', do you think that the value of x
is a memory address?

Nov 9 '08 #160

greg

Steven D'Aprano wrote:

Not according to my Comp Sci lecturers back in the day, and not according
to my Pascal books.

Pascal books will tell you what call-by-value means
in Pascal. You can't just blindly take that description
and apply it to other languages, just as you can't
take what your Pascal book says about assigment and
apply it blindly to Python without getting into
trouble.

Describing call-by-value as "copying the value" works
in Pascal, because "assignment" and "copy" are synonyms
in that language. But they're not synonyms in all
languages, so a language-independent definition of
call-by-value needs to describe it in a more general
way.

Refusing to accept that a more general definition
exists just because it's not mentioned in your Pascal
book is a little absurd.

--
Greg

Nov 9 '08 #161

greg

Arnaud Delobelle wrote:

What's a variable reference?

It's a reference to a variable. It's what gets passed behind
the scenes when you use a VAR parameter in Pascal, or a
ByRef parameter in VB.

What you're saying is that in the code below, when foo(q) is called
then 'p' in foo is another name for q in main. Right?

struct point {
int x;
int y;
}

int foo(point p) {
p.x = 42;
}

int main() {
point q = {0, 0};
foo(q);
/* So now you're saying that q.x == 0 ? */
}

No. Passing q by value means that the value of the expression 'q',
whatever that is in the language concerned, gets assigned to the
local variable 'p', whatever *that* means in the language concerned.

Because of the way C assignment works, the result is that p ends
up with a copy of the whole struct.

Because of the way Python assignment works, the result is that
p and q end up referring to the same object.

The difference is *entirely* due to the difference in the semantics
of assignment between the two languages. Once you've taken that
into account, there is no need to look for difference in the
parameter passing scheme.

--
Greg

Nov 9 '08 #162

greg

Dennis Lee Bieber wrote:

You must have missed all the threads about "binding" then... Wherein
a Python "assignment statement" "binds the LHS name to the RHS object"
rather than "assigns the RHS object value to the LHS"

I know that it is sometimes referred to that way. But
nobody seems to get worked up into a religious fervour
and insist that the word "assignment" be banned from the
Python terminology lexicon, the way some people seem to
do about words such as "value" and "reference".

If we can all get along nicely and accept that "assignment"
is an acceptable term, among alternatives, for something that
has an analogy, if not an exact equivalent, in other languages,
why can't we do the same for "reference" and "call by value"?

--
Greg

Nov 9 '08 #163

Arnaud Delobelle

greg <gr**@cosc.canterbury.ac.nzwrites:

Arnaud Delobelle wrote:

>What's a variable reference?

It's a reference to a variable. It's what gets passed behind
the scenes when you use a VAR parameter in Pascal, or a
ByRef parameter in VB.

Do you mean you can't do the following C++ snippet in Pascal or VB? I
haven't used Pascal for more than 20 year and I have never used VB, so
this is a real question.

foo(int &x) {
x = 7;
}

struct bar {
int i;
float j;
};

int main() {
int a[10];
bar b;
// What is passed to foo below is obviously not a 'variable
// reference' as the argument is not a variable.
foo(a[3]); // Now a[3] == 7
foo(b.i); // Now b.i == 7
}

[...]

Passing q by value means that the value of the expression 'q',
whatever that is in the language concerned, gets assigned to the
local variable 'p', whatever *that* means in the language concerned.

Because of the way C assignment works, the result is that p ends
up with a copy of the whole struct.

Because of the way Python assignment works, the result is that
p and q end up referring to the same object.

The difference is *entirely* due to the difference in the semantics
of assignment between the two languages. Once you've taken that
into account, there is no need to look for difference in the
parameter passing scheme.

I'm not sure that your definition of 'call by value' is widely
accepted. If it was, then this thread wouldn't exist.

I've tried to google for an authoritative definition but it's harder
than I thought. This definition comes up everywhere though.

call-by-value

(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.

[This from http://dictionary.reference.com/browse/call-by-value]

It seems to me that it more or less is the definition that most people
on this thread has been implicitly using.

--
Arnaud

Nov 9 '08 #164

Marc 'BlackJack' Rintsch

On Sun, 09 Nov 2008 11:17:28 +0000, Arnaud Delobelle wrote:

greg <gr**@cosc.canterbury.ac.nzwrites:

>Arnaud Delobelle wrote:

>>What's a variable reference?

It's a reference to a variable. It's what gets passed behind the scenes
when you use a VAR parameter in Pascal, or a ByRef parameter in VB.

Do you mean you can't do the following C++ snippet in Pascal or VB? I
haven't used Pascal for more than 20 year and I have never used VB, so
this is a real question.

foo(int &x) {
x = 7;
}

struct bar {
int i;
float j;
};

int main() {
int a[10];
bar b;
// What is passed to foo below is obviously not a 'variable
// reference' as the argument is not a variable.
foo(a[3]); // Now a[3] == 7
foo(b.i); // Now b.i == 7
}

Translated to Pascal:

Program Test;

Type
Bar = Record
i: Integer;
j: Real;
End;

Var a: Array[0..9] Of Integer;
b: Bar;

Procedure Foo(Var x:Integer);
Begin
x := 7;
End;

Begin
Foo(a[3]);
WriteLn(a[3]); {Prints 7.}
Foo(b.i);
WriteLn(b.i); {Prints 7.}
End.

In "reality" I would not expect that anything is passed here but that the
compiler inlines it as direct assignment. Should read: Copying the bit
pattern of a 7 into the fixed memory locations. :-)

Ciao,
Marc 'BlackJack' Rintsch

Nov 9 '08 #165

greg wrote:

>
No. Passing q by value means that the value of the expression 'q',
whatever that is in the language concerned, gets assigned to the
local variable 'p', whatever *that* means in the language concerned.

In other words, as I acknowledged in my other post, one can say that all
calling is calling by value.

Nov 9 '08 #166

greg

Arnaud Delobelle wrote:

// What is passed to foo below is obviously not a 'variable
// reference' as the argument is not a variable.
foo(a[3]); // Now a[3] == 7
foo(b.i); // Now b.i == 7

Yes, it is. By "variable" I mean what C calls an lvalue,
i.e. something you can assign to.

I'm not sure that your definition of 'call by value' is widely
accepted. If it was, then this thread wouldn't exist.

It seems to be accepted by the Java and VB community,
judging by what they refer to as call-by-value in those
languages.

You won't necessarily find it written down anywhere in
the exact words I used. I have reverse-engineered it
from the characteristics of a wide variety of languages
that use the term call-by-value to describe one of their
parameter passing mechanisms. Think of it as a theory
that fits the observed linguistic facts.

(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 hinges on what exactly is meant by "changes to
the arguments". In Python it can only mean assigning
directly to the bare name -- anything else isn't
changing the argument itself, but something else to
which the argument refers.

--
Greg

Nov 10 '08 #167

greg

Terry Reedy wrote:

In other words, as I acknowledged in my other post, one can say that all
calling is calling by value.

No, those are not other words for what I'm saying.
Call by reference is very demonstrably different
from call by value, as has been pointed out a large
number of times already.

--
Greg

Nov 10 '08 #168

greg wrote:

Arnaud Delobelle wrote:

> (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 hinges on what exactly is meant by "changes to
the arguments".

Mutating them, like Python does, which is why calling Python CBV leads
people to write buggy code.

>In Python it can only mean assigning
directly to the bare name -- anything else isn't
changing the argument itself, but something else to
which the argument refers.

Hogwash. The argument is the object and mutable objects can be changed
as seen by the caller.

Nov 10 '08 #169

Joe Strout

On Nov 10, 2008, at 8:30 AM, Terry Reedy wrote:

>That hinges on what exactly is meant by "changes to
the arguments".

Mutating them, like Python does, which is why calling Python CBV
leads people to write buggy code.

In Python it can only mean assigning
directly to the bare name -- anything else isn't
changing the argument itself, but something else to
which the argument refers.

Hogwash. The argument is the object and mutable objects can be
changed as seen by the caller.

By that definition, Java, REALbasic, C++, and VB.NET are all call-by-
reference too (even when explicitly using the "ByVal" keyword in RB/
VB.NET). This will come as quite a shock to the designers and users
of those languages.

For what it's worth, I think Greg (double-quoted above) has it exactly
right. The argument in any of these languages is an object reference;
changing the object and changing the object reference are two
different things.

Best,
- Joe

Nov 10 '08 #170

Joe Strout wrote:

On Nov 10, 2008, at 8:30 AM, Terry Reedy wrote:

>>That hinges on what exactly is meant by "changes to
the arguments".

Mutating them, like Python does, which is why calling Python CBV leads
people to write buggy code.

>In Python it can only mean assigning
directly to the bare name -- anything else isn't
changing the argument itself, but something else to
which the argument refers.

Hogwash. The argument is the object and mutable objects can be
changed as seen by the caller.

By that definition, Java, REALbasic, C++, and VB.NET are all
call-by-reference too (even when explicitly using the "ByVal" keyword in
RB/VB.NET). This will come as quite a shock to the designers and users
of those languages.

For what it's worth, I think Greg (double-quoted above) has it exactly
right. The argument in any of these languages is an object reference;
changing the object and changing the object reference are two different
things.

Nov 10 '08 #171

Joe Strout wrote:

On Nov 10, 2008, at 8:30 AM, Terry Reedy wrote:

>>That hinges on what exactly is meant by "changes to
the arguments".

Mutating them, like Python does, which is why calling Python CBV leads
people to write buggy code.

>In Python it can only mean assigning
directly to the bare name -- anything else isn't
changing the argument itself, but something else to
which the argument refers.

Hogwash. The argument is the object and mutable objects can be
changed as seen by the caller.

By that definition, Java, REALbasic, C++, and VB.NET are all
call-by-reference too (even when explicitly using the "ByVal" keyword in
RB/VB.NET). This will come as quite a shock to the designers and users
of those languages.

For what it's worth, I think Greg (double-quoted above) has it exactly
right. The argument in any of these languages is an object reference;

In the Python I am talking about, the language defined in the Python
Reference Manual, arguments are objects.

Bye,

tjr

Nov 10 '08 #172

On Nov 7, 3:03*pm, Arnaud Delobelle <arno...@googlemail.comwrote:

1. Is Napoleon a copy of Dobby or are they the same cat?

2. Is Polion a copy of Napoleon or are they the same cat?

3. When we got rid of Napoleon's fleas, was Nelson deflea-ed as well?

4. When Napoleon died, did Nelson die as well?

5. When we got a new Napoleon, does this mean that our neighbours got a
* *new Nelson?

Now a question about the questions about the story:

* *To be able to understand the story and answer questions 1-5, do we
* *need to think of Napoleon, Nelson and Polion as variables containing
* *references to cat objects, or is it enough to think of them as three
* *names for cats?

Do you ever say to someone, "'Napoleon' will no longer refer to
Nelson. It is this lobster now instead", while you are holding a
lobster?

My point is that the assignment operation is rare in natural language.

Some examples:

unitedstates.president= people['Barack Obama']
catholicchurch.pope= people['Joseph Ratzinger']
chicagocubs.manager= people['Lou Pienella']

That is, in January, 'The President' will start to refer to a
different person. But you don't see:

popstars['Britney Spears']= people['Ricky Martin']
people['Richard Nixon']= people['Ronald Reagan']

You also have expressions, such as 'the man in the corner drinking
Coke' and 'the first street on the right', which would not be likely
to be modeled as attributes, per se, such as:

corner.men.drinking['Coke']
street.ontheright[0]

You'd more likely use:

"select id from people where standingin = 'corner' and drinking =
'coke'"
"select id from streets where distanceonright =
min( distanceonright )"

Maybe in the future we'll see relational code, rather than
hierarchical subclasses:

>>"select fly from birds where name = 'bluejay'"

'flap_wings()'

>>"select fly from birds where name = 'ostrich'"

'raise CannotFlyException'

Nov 10 '08 #173

Arnaud Delobelle

Aaron Brady <ca********@gmail.comwrites:

Do you ever say to someone, "'Napoleon' will no longer refer to
Nelson. It is this lobster now instead", while you are holding a
lobster?

Not explicitly. But in the course of conversation I might refer to
Napoleon, meaning Napoleon Bonaparte (1769 - 1821) or Napoleon III (1808
- 1873). There would then be an implicit 'rebinding' of the name Napoleon.

My point is that the assignment operation is rare in natural language.

My point was to get away from a model for Python which was built on its
likely implementation and to hint that we can build one using the naive
concept of 'name for a thing' instead. IOW, 'call by value' is an
unnecessary obfuscation of what *actually* happens (even though it may
describe accurately the artifacts employed by an implementation)

I'm glad that you thought about it!

--
Arnaud

Nov 10 '08 #174

On Nov 10, 2:45*pm, Arnaud Delobelle <arno...@googlemail.comwrote:

Aaron Brady <castiro...@gmail.comwrites:
Do you ever say to someone, "'Napoleon' will no longer refer to
Nelson. *It is this lobster now instead", while you are holding a
lobster?

Not explicitly. *But in the course of conversation I might refer to
Napoleon, meaning Napoleon Bonaparte (1769 - 1821) or Napoleon III (1808
- 1873). *There would then be an implicit 'rebinding' of the name Napoleon.

My point is that the assignment operation is rare in natural language.

My point was to get away from a model for Python which was built on its
likely implementation and to hint that we can build one using the naive
concept of 'name for a thing' instead. *IOW, 'call by value' is an
unnecessary obfuscation of what *actually* happens (even though it may
describe accurately the artifacts employed by an implementation)

I'm glad that you thought about it!

I agree with Terry that all calling is call-by-value, and Steven that
all calling is call-by-bit-flipping. I agree with Joe that call-by-
object is a special case of call-by-value.

I thought of another way Python's passing method could be
implemented. Parameters are passed as namespace-name pairs, and every
time a variable occurs, it's looked up in the namespace it's in. If
it's changed (concurrently) in the outer scope, a copy is made into
the inner scope. If it's changed in the inner scope, a new entry is
added there.

It's still call-by-value (and bit-flipping) on some level, in the
trivial sense. What else is it?

Nov 10 '08 #175

Joe Strout

On Nov 10, 2008, at 2:30 PM, Aaron Brady wrote:

I agree with Terry that all calling is call-by-value, and Steven that
all calling is call-by-bit-flipping. I agree with Joe that call-by-
object is a special case of call-by-value.

Woo! Almost sounds like approaching consensus. :)

However, I'm sorry to say that I think both Terry's and Steven's
descriptions are unhelpful. There really are important distinctions
among parameter evaluation strategies. Call-by-reference is not call-
by-value (though it is call-by-bit-flipping, but that's too low a
level).

But if we can agree that call-by-sharing (which I believe is the more
widely documented term than "call-by-object") is a special case of
call-by-value, when the parameters are object references, then I think
we may have a winner.

Best,
- Joe

Nov 10 '08 #176

On Mon, 10 Nov 2008 08:39:58 -0700, Joe Strout wrote:

By that definition, Java, REALbasic, C++, and VB.NET are all call-by-
reference too (even when explicitly using the "ByVal" keyword in RB/
VB.NET).

No, they are not call-by-reference either. They are call-by-sharing, just
like Python and CLU.

--
Steven

Nov 11 '08 #177

On Mon, 10 Nov 2008 23:16:13 +1300, greg wrote:

> (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 hinges on what exactly is meant by "changes to the arguments". In
Python it can only mean assigning directly to the bare name -- anything
else isn't changing the argument itself, but something else to which the
argument refers.

But the name isn't the argument. The argument to a function is an object,
not a name. You can't write a function in Python that takes a name as an
argument[1], which would be equivalent to Pascal's "var" parameters.

Take a function foo that takes one formal parameter x. Pass an actual
argument y to it. The argument is the object currently bound to y, not
the name y. Nothing inside foo can rebind the name y because foo doesn't
see the name y, it sees the object. Rebinding (or deleting) the name x
inside foo does nothing to the object bound to y, or the name y.

[1] You can pass a string representing the name to a function, which can
then use some combination of setattr, globals(), exec etc to work with
the name represented by that string. But you're still passing an object
to the function, not a name.
--
Steven

Nov 11 '08 #178

greg

Arnaud Delobelle wrote:

But in the course of conversation I might refer to
Napoleon, meaning Napoleon Bonaparte (1769 - 1821) or Napoleon III (1808
- 1873).

That's more like referring to the name 'Napoleon' in
two different namespaces. The original binding still
exists, you're just switching contexts.

My point was to get away from a model for Python which was built on its
likely implementation and to hint that we can build one using the naive
concept of 'name for a thing' instead.

I don't believe it's possible to build any complete and
correct model of Python behaviour without including some
concept equivalent to a reference.

You can talk about names written on PostIt notes and
such like, but that only gets you a short way. It doesn't
easily handle names in different namespaces, or references
that exist without simple names, e.g. list and tuple
items. Trying to repair these deficiencies only leads to
increasingly bizarre and contrived mental pictures.

On the other hand, if you explicitly include the concept
of a reference from the beginning, everything is quite
clear and consistent.

In other words, the model should be as simple as possible
but no simpler. Leaving out references makes it too
simple.

Another point I'd like to make is that there is nothing
inherently low-level about the concept of a reference.
It doesn't have to be implemented as a memory address or
any other particular machine-level thing. It's possible to
talk about Python object references in a completely
implementation-independent way.

Also, just because you don't explicitly refer to them and
manipulate them at the language level doesn't mean they
don't exist. To think otherwise is like thinking that air
doesn't exist just because you can't see it. There are
plenty of experiments which clearly indicate its existence.
Likewise, there are plenty of experiments that you can
perform with any Python interpreter that reveal the
existence of references, or something equivalent to them.

--
Greg

Nov 11 '08 #179

greg

Aaron Brady wrote:

I thought of another way Python's passing method could be
implemented. Parameters are passed as namespace-name pairs, and every
time a variable occurs, it's looked up in the namespace it's in. If
it's changed (concurrently) in the outer scope, a copy is made into
the inner scope. If it's changed in the inner scope, a new entry is
added there.

That sounds like a kind of copy-on-write. It's certainly not
call-by-value by any sane interpretation (contrary to your
assertion that "all calling is call-by-value").

--
Greg

Nov 11 '08 #180

greg

Steven D'Aprano wrote:

But the name isn't the argument. The argument to a function is an object

The *formal* argument *is* a name, and that's what
the phrase "changes to the arguments within the called
procedure" is talking about.

Take a function foo that takes one formal parameter x. Pass an actual
argument y to it. The argument is the object currently bound to y, not
the name y. Nothing inside foo can rebind the name y because foo doesn't
see the name y, it sees the object.

More to the point, it sees the *name x* rather than the
name y, and rebinding the name x doesn't change the binding
of name y. Therefore, the name y has been passed by value,
not by reference.

[1] You can pass a string representing the name to a function, which can
then use some combination of setattr, globals(), exec etc to work with
the name represented by that string.

This would be the Python equivalent of the strategy used
in C to emulate call-by-reference -- and it's needed for
the same reason, i.e. the language itself only provides
call-by-value. So you pass a value that you can manually
dereference to get the same effect.

--
Greg

Nov 11 '08 #181

On Tue, 11 Nov 2008 16:54:10 +1300, greg wrote:

Steven D'Aprano wrote:

>But the name isn't the argument. The argument to a function is an
object

The *formal* argument *is* a name, and that's what the phrase "changes
to the arguments within the called procedure" is talking about.

If you equate "arguments within the called procedure" to the *name* of
the arguments, then changing the arguments would mean changing the NAME,
not the object bound to the name. That is, something like this:

def foo(x):
y = x
del x

except as a single operation. I'm sure that's not what you intended to
say, but that's what you have said. Except for del and rebinding, Python
level code does not allow you to do anything to *names*, only to objects.
But I'm sure you know this, which makes your claim all the more confused.

>Take a function foo that takes one formal parameter x. Pass an actual
argument y to it. The argument is the object currently bound to y, not
the name y. Nothing inside foo can rebind the name y because foo
doesn't see the name y, it sees the object.

More to the point, it sees the *name x* rather than the name y, and
rebinding the name x doesn't change the binding of name y. Therefore,
the name y has been passed by value, not by reference.

The term for what you have just said is "non sequitor", Latin for "it
does not follow". The _name_ y is not passed AT ALL. If there is a value
that is passed, it is the object bound to y, and not any name at all.

If you equate "value" with "object", as you suggested some posts ago,
then it could be argued that Python is call-by-value (for value=object)
but because "call by value" has connotations and implications that do not
apply to Python, we prefer to avoid the misleading and confusing term
c-b-v in preference to Barbara Liskov's term "call by sharing" or "call
by object".

At least some sections of the Java community seem to prefer a misleading
and confusing use of the word "value" over clarity and simplicity, but I
for one do not agree with them.

>[1] You can pass a string representing the name to a function, which
can then use some combination of setattr, globals(), exec etc to work
with the name represented by that string.

This would be the Python equivalent of the strategy used in C to emulate
call-by-reference -- and it's needed for the same reason, i.e. the
language itself only provides call-by-value. So you pass a value that
you can manually dereference to get the same effect.

In the general case, you can't emulate call-by-reference by passing a
name, because you don't know what the name of an object is. Obviously I
can hard-code some names:

def swap(x, y):
# arguments x and y are actually pointless
g = globals()
g['x'], g['y'] = g['y'], g['x']
but you can't emulate c-b-r's ability to swap arbitrary names determined
by the compiler. The reason is that when you call a function with an
argument, the function sees only the object, and the object does not know
what name(s) is bound to it.
You could do this:

def swap(x_name, y_name):
g = globals()
g[x_name], g[y_name] = g[y_name], g[x_name]

which gives you something a little closer to c-b-r, but it still isn't
the same thing. Some major differences:

- you can't affect values unless they are bound to a name, that is no
swapping of anonymous values, e.g. swap(a[4], a[8]) could not work;

- within a nested scope, you can't affect anything unless it is in the
global scope;

- you need to know the name to apply at runtime, there is no way to
programmatically discover it.

The third point is the most telling. Consider the Pascal procedure:

procedure swap(var x, var y: integer):
var tmp: integer;
begin
tmp := x;
x := y;
y := tmp;
end;
Given two integer variables a and b, you call the procedure swap(a, b),
and the compiler can determine what memory addresses are used. If Pascal
was like Python, you would have to determine the addresses yourself:

a := 1;
b := 2;
swap(12693024, 190342874);

after which a would equal 2 and b would equal 1. Obviously Pascal is not
like that, but Python is (using names instead of memory locations). This
proves that Python names are nothing like Pascal call-by-reference
arguments. Passing a name is *not* Python's way to emulate call-by-
reference.
--
Steven

Nov 11 '08 #182

Steve Holden

greg wrote:

Arnaud Delobelle wrote:
>But in the course of conversation I might refer to
Napoleon, meaning Napoleon Bonaparte (1769 - 1821) or Napoleon III (1808
- 1873).

That's more like referring to the name 'Napoleon' in
two different namespaces. The original binding still
exists, you're just switching contexts.

>My point was to get away from a model for Python which was built on its
likely implementation and to hint that we can build one using the naive
concept of 'name for a thing' instead.

I don't believe it's possible to build any complete and
correct model of Python behaviour without including some
concept equivalent to a reference.

You can talk about names written on PostIt notes and
such like, but that only gets you a short way. It doesn't
easily handle names in different namespaces, or references
that exist without simple names, e.g. list and tuple
items. Trying to repair these deficiencies only leads to
increasingly bizarre and contrived mental pictures.

On the other hand, if you explicitly include the concept
of a reference from the beginning, everything is quite
clear and consistent.

Yes. References do explain things very well, since the model is in exact
agreement with the reality of the implementation.

In other words, the model should be as simple as possible
but no simpler. Leaving out references makes it too
simple.

Another point I'd like to make is that there is nothing
inherently low-level about the concept of a reference.
It doesn't have to be implemented as a memory address or
any other particular machine-level thing. It's possible to
talk about Python object references in a completely
implementation-independent way.

Indeed one might make use of some object store, and references would
still be useful even if they weren't memory addresses.

Also, just because you don't explicitly refer to them and
manipulate them at the language level doesn't mean they
don't exist. To think otherwise is like thinking that air
doesn't exist just because you can't see it. There are
plenty of experiments which clearly indicate its existence.
Likewise, there are plenty of experiments that you can
perform with any Python interpreter that reveal the
existence of references, or something equivalent to them.

Good stuff. I have come to the conclusion that this thread is mostly
best left alone, since the remaining participants appear to have agreed
on Python's semantics and now continue to argue about what name should
be used to describe them.

regards
Steve
--
Steve Holden +1 571 484 6266 +1 800 494 3119
Holden Web LLC http://www.holdenweb.com/

Nov 11 '08 #183

greg

Steven D'Aprano wrote:

If you equate "arguments within the called procedure" to the *name* of
the arguments, then changing the arguments would mean changing the NAME

If "changing the name" means "rebinding the name",
then I agree -- that's exactly the point I was trying to
make.

If you equate "value" with "object", as you suggested some posts ago,

*I* didn't suggest that, someone else did. I was just
pointing out that you can use the word that way if you
want, as long as you're consistent about it. And being
consistent means using it in the same way when talking
about assignment and about by-value parameter passing.
If you insist that one of these implies copying the
"value" but the other doesn't, then you're being
inconsistent.

At least some sections of the Java community seem to prefer a misleading
and confusing use of the word "value" over clarity and simplicity, but I
for one do not agree with them.

I don't see anything inherently confusing or misleading
about it. Confusion only arises when some people jump up
and say that it's wrong to use the terms that way, because
it might cause confusion...

In the general case, you can't emulate call-by-reference by passing a
name, because you don't know what the name of an object is.

That's true, you need to communicate the namespace as
well, either implicitly or explicitly. So a
(namespace, name) pair, or a (sequence, index) pair
in the case of a sequence item, would be the equivalent
of a "reference" in the sense meant by "call by reference".

--
Greg

Nov 11 '08 #184

greg

Here is the definition of call-by-value from the
"Revised Report on the Algorithmic Language Algol 60"
<http://www.masswerk.at/algol60/report.htm>:

4.7.3.1. Value assignment (call by value). All formal parameters quoted in the
value part of the procedure declaration heading are assigned the values (cf.
section 2.8. Values and types) of the corresponding actual parameters, these
assignments being considers as being performed explicitly before entering the
procedure body. The effect is as though an additional block embracing the
procedure body were created in which these assignments were made to variables
local to this fictitious block with types as given in the corresponding
specifications (cf. section 5.4.5).

There you have it -- call by value is offially defined in
terms of assignment. There is no mention in there of copying.

So it's perfectly correct to use it in relation to Python.

--
Greg

Nov 12 '08 #185

Aahz

In article <6n************@mid.individual.net>,
greg <gr**@cosc.canterbury.ac.nzwrote:

>
Here is the definition of call-by-value from the
"Revised Report on the Algorithmic Language Algol 60"
<http://www.masswerk.at/algol60/report.htm>:

4.7.3.1. Value assignment (call by value). All formal parameters quoted in the
value part of the procedure declaration heading are assigned the values (cf.
section 2.8. Values and types) of the corresponding actual parameters, these
assignments being considers as being performed explicitly before entering the
procedure body. The effect is as though an additional block embracing the
procedure body were created in which these assignments were made to variables
local to this fictitious block with types as given in the corresponding
specifications (cf. section 5.4.5).

There you have it -- call by value is offially defined in
terms of assignment. There is no mention in there of copying.

So it's perfectly correct to use it in relation to Python.

Except, of course, for the fact that it is generally misleading.
--
Aahz (aa**@pythoncraft.com) <* http://www.pythoncraft.com/

"It is easier to optimize correct code than to correct optimized code."
--Bill Harlan

Nov 12 '08 #186

On Wed, 12 Nov 2008 13:10:10 +1300, greg wrote:

Here is the definition of call-by-value from the "Revised Report on the
Algorithmic Language Algol 60"
<http://www.masswerk.at/algol60/report.htm>:

Why should anyone take the "Revised Report on the Algorithmic Language
Algol 60" as the "official" (only?) definition of call-by-value for all
languages everywhere?

Particularly since in practice, people's *understanding* of such terms
have more to do with common practice than formal definitions. You're
welcome to tell people that tomatoes are actually berries from the Deadly
Nightshade family of plants, rather than vegetables, but if you do so you
better follow it up with further explanations.

4.7.3.1. Value assignment (call by value). All formal parameters quoted
in the value part of the procedure declaration heading are assigned the
values (cf. section 2.8. Values and types) of the corresponding actual
parameters, these assignments being considers as being performed
explicitly before entering the procedure body. The effect is as though
an additional block embracing the procedure body were created in which
these assignments were made to variables local to this fictitious block
with types as given in the corresponding specifications (cf. section
5.4.5).

I notice that you deleted the last sentence of the definition. I quote:

"As a consequence, variables called by value are to be considered as
nonlocal to the body of the procedure, but local to the fictitious block
(cf. section 5.4.3)."

And what's the fictitious block? As I understand it, their intention is
to say that calling a procedure foo(x) with an actual argument y should
be considered the same as:

# start a new block (a new scope, in Python terminology)
x = y # behave as if we explicitly assigned y to x
foo(x) # enter the body of foo with argument x local to the new block
What are the consequences of such assignment? Unfortunately, assignment
isn't unambiguously defined:
"4.2.3. Semantics. Assignment statements serve for assigning the value of
an expression to one or several variables or procedure identifiers.
Assignment to a procedure identifier may only occur within the body of a
procedure defining the value of a function designator (cf. section
5.4.4). The process will in the general case be understood to take place
in three steps as follows:
4.2.3.1. Any subscript expression occurring in the left part variables
are evaluated in sequence from left to right.
4.2.3.2. The expression of the statement is evaluated.
4.2.3.3. The value of the expression is assigned to all the left part
variables, with any subscript expressions having values as evaluated in
step 4.2.3.1."
In other words, assignment takes three steps:

(1) evaluate the subscript expressions on the left part (presumably of
the statement);

(2) evaluate the expression of the statement (presumably the right hand
side, but the document doesn't make that clear);

(3) assign the value of the expression.

Got that? Assignment means the value is assigned. Glad that's all clear
then.

So given an assignment of x = y in Algol, it isn't clear from this
document whether x and y refer to the same value, or if they merely have
the same value by equality. That second case would imply copying. To put
it in Python terms, following x = y we know that x == y is true but we
don't know whether id(x) == id(y).
Can we at least determine what variables and values are? Well, almost...

"3.1.3. Semantics. A variable is a designation given to a single value."

Okay, a variable is a designation (a name if you prefer) for a value. So
what's a value?
"2.8. Values and types

A value is an ordered set of numbers (special case: a single number), an
ordered set of logical values (special case: a single logical value), or
a label.
Certain of the syntactic units are said to possess values. These values
will in general change during the execution of the program The values of
expressions and their constituents are defined in section 3. The value of
an array identifier is the ordered set of values of the corresponding
array of subscripted variables (cf. section 3.1.4.1)."
Now we're getting somewhere! Values are sets of numbers or sets of true/
false logical elements. Hmmm... apparently strings aren't values in
Algol. Oh well.

But one thing is clear: values aren't references. Given the assignment
x=1, the value of x is not "a reference to 1" but 1 itself. So the one
thing we can unambiguously say is that Algol's assignment model is not
the same as Python's assignment model.

--
Steven

Nov 12 '08 #187