Finding the instance reference of an object

[greg]

Re: Finding the instance reference of an object

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

[Steven D'Aprano]

Re: Finding the instance reference of an object

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
programmaticall y 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

[Steve Holden]

Re: Finding the instance reference of an object [long and probablyboring]

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

+1

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/

[greg]

Re: Finding the instance reference of an object

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

[greg]

Official definition of call-by-value (Re: Finding the instance reference...)

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

[Aahz]

Re: Official definition of call-by-value (Re: Finding the instance reference...)

In article <6nul1qF100urU1 @mid.individual .net>,
greg <greg@cosc.cant erbury.ac.nzwro te:

>
>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
>specificatio ns (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 (aahz@pythoncra ft.com) <* http://www.pythoncraft.com/

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

[Steven D'Aprano]

Re: Official definition of call-by-value (Re: Finding the instancereferen ce...)

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

[Steven D'Aprano]

Re: Official definition of call-by-value (Re: Finding the instancereferen ce...)

On Wed, 12 Nov 2008 02:44:42 +0000, Steven D'Aprano wrote:

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.

Sorry, this is very misleading.

What I meant to say is that if you are one of those people who insist
that values in Python are references, then Algol's assignment model is
not that same as what you understand Python assignment to be.

I am very happy to say that x=1 implies that the value of x is the object
1 itself, in fact I would insist on such a definition of value.

If you insist that Python is call by value, the only way that can work is
by defining values to be references, which is nothing like Algol.



--
Steven

[Arnaud Delobelle]

Re: Official definition of call-by-value (Re: Finding the instance reference...)

Steven D'Aprano <steven@REMOVE. THIS.cybersourc e.com.auwrites:

I am very happy to say that x=1 implies that the value of x is the object
1 itself, in fact I would insist on such a definition of value.
>
If you insist that Python is call by value, the only way that can work is
by defining values to be references

That's a neat and concise way of summarising this whole thread.

--
Arnaud

[Fredrik Lundh]

Re: Official definition of call-by-value (Re: Finding the instancereferen ce...)

Aahz wrote:

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

It's not only misleading, it's also a seriously flawed reading of the
original text - the Algol 60 report explicitly talks about assignment of
*values*.

I'm not aware of any language where a reference to an object, rather
than the *contents* of the object, is seen as the object's actual value.
It's definitely not true for Python, at least.

</F>

[greg]

Re: Official definition of call-by-value (Re: Finding the instancereferen ce...)

Steven D'Aprano wrote:

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?

Since the term was more or less invented by the people
who designed Algol, I thought it would be a good idea to
find out, from as close to the source as possible, what
*they* intended it to mean.

Particularly since in practice, people's *understanding* of such terms
have more to do with common practice than formal definitions.

If "common practice" includes languages such as Java,
VB and RealBasic, then it accords with the original
definition, as far as I can see.

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)."

I didn't include that because it's not really relevant --
it's an artifact of the way they describe the effect of a
procedure call by conceptually substituting the call with
the text of the called procedure. You can equally well
think of the parameters as being in the same scope as the
rest of the procedure's locals.

What are the consequences of such assignment?

It doesn't matter what assignment means in Algol, because
we're talking about Python. We already agree on what assignment
means in Python -- or at least I hope we do!

--
Greg

[greg]

Re: Official definition of call-by-value (Re: Finding the instancereferen ce...)

Steven D'Aprano wrote:

If you insist that Python is call by value, the only way that can work is
by defining values to be references, which is nothing like Algol.

No, that's not the only way. You can also make it work
by accepting the original definition of call-by-value
at face value -- i.e. as equivalent to assignment,
without any implication of copying beyond what
assignment itself implies.

--
Greg

[greg]

Re: Official definition of call-by-value (Re: Finding the instancereferen ce...)

Fredrik Lundh wrote:

It's not only misleading, it's also a seriously flawed reading of the
original text - the Algol 60 report explicitly talks about assignment of
*values*.

Do you agree that an expression in Python has a value?

Do you agree that it makes sense to talk about assigning
that value to something?

If so, what is there to stop us from applying the Algol
definition to Python?

--
Greg

[Steve Holden]

Re: Official definition of call-by-value (Re: Finding the instancereferen ce...)

greg wrote:

Fredrik Lundh wrote:
>

>It's not only misleading, it's also a seriously flawed reading of the
>original text - the Algol 60 report explicitly talks about assignment
>of *values*.

>
Do you agree that an expression in Python has a value?
>

Most expressions have values. The ones whose evaluations don't raise
exceptions.

Do you agree that it makes sense to talk about assigning
that value to something?
>

No. Why do you think that we are (mostly) careful to talk about binding
names and values instead?

If so, what is there to stop us from applying the Algol
definition to Python?
>

Apparently nothing. But then various participants in this thread have
demonstrated an apparently infinite capacity to split hairs with the
presumed intention of proving themselves right and others wrong. By now
you are arguing at the level of whether turquoise can be called blue.
Frankly, my dear, I don't give a damn.

Now, can we get on to something substantive like how many angels can
dance on the head of a pin?

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

[Francesco Guerrieri]

Re: Official definition of call-by-value (Re: Finding the instancereferen ce...)

On Wed, Nov 12, 2008 at 2:01 PM, Steve Holden <steve@holdenwe b.comwrote:

Now, can we get on to something substantive like how many angels can
dance on the head of a pin?
>

Oh, come on, that's too easy! 42.
I thought that by now everybody knew that.

Francesco