Finding the instance reference of an object

[Grant Edwards]

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

On 2008-11-12, Steve Holden <steve@holdenwe b.comwrote:

greg wrote:

I stopped paying much attention to this thread a while ago, but
you've got to admire the persistence of somebody who soldiers
on even though Aahz, Fredrik Lund, and Steve Holden are all on
the other side of the argument...

--
Grant Edwards grante Yow! Look DEEP into the
at OPENINGS!! Do you see any
visi.com ELVES or EDSELS ... or a
HIGHBALL?? ...

[Fredrik Lundh]

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

greg 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?

Python's definition of the word "value" can be found in the language
reference:

http://docs.python.org/reference/datamodel.html#objects-values-and-types

Using that definition, a Python expression yields an object, not an
object value.

For comparison, here's Algol's definition of the word "value":

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

It should be obvious to anyone that Python is not Algol.

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

The fact that we're talking about Python. Python is not Algol.

</F>

[Aahz]

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

In article <JYmdnZrK7c7PYI fUnZ2dnUVZ_tXin Z2d@posted.visi >,
Grant Edwards <invalid@invali dwrote:

>On 2008-11-12, Steve Holden <steve@holdenwe b.comwrote:

>greg wrote:

>
>I stopped paying much attention to this thread a while ago, but
>you've got to admire the persistence of somebody who soldiers
>on even though Aahz, Fredrik Lund, and Steve Holden are all on
>the other side of the argument...

QOTW! ;-)
--
Aahz (aahz@pythoncra ft.com) <* http://www.pythoncraft.com/

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

[George Sakkis]

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

On Nov 12, 4:05 pm, Fredrik Lundh <fred...@python ware.comwrote:

greg 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?

>
Python's definition of the word "value" can be found in the language
reference:
>
http://docs.python.org/reference/dat...lues-and-types

Quoting the relevant part:

"The value of some objects can change. Objects whose value can change
are said to be mutable; objects whose value is unchangeable once they
are created are called immutable."

Strictly speaking that's not a definition; it doesn't say what a value
is, only how it relates to objects. But regardless, according to this,
a Python value is what the rest of the world usually calls "state",
while a value in a non-Python context is usually a synonym of
"object" (in the general sense, e.g. for Java including both
primitives and object references), i.e. there's the following
approximate mapping in terminology:

Python jargon Non-python jargon
=============== ============
object value (primitive or composite)
value state (set of an object's attribute bindings)

Thus both call-by-value and call-by-object can be correct
descriptions, depending on who you ask.

George

[Craig Allen]

Re: Finding the instance reference of an object

arguably even older than that to Lisp.
>

Firstly, thanks to those that have responded to my part in this
debate, I have found it very informative and interesting as I have the
entire thread. However, with regard to comments that I led myself
astray, I want to reiterate the one thing I find determinably
important in this... I did not go astray because I did not fret what
the words meant and try to draw anything from that. I learned exactly
what would happen when I passed arguments different ways, and I
learned that well and accurately. Then I mused what to call it all. At
no time was I astray because I think to really be astray would be to
have a misunderstandin g on what happens, not on what we call what
happens.

but I will concede that trying to use call-by-name is not a viable
idea as it's yet another term that is already taken. I did not think
too hard what the distinction is, and as far as I know it's as good a
candidate for what we call it as anything else, but I certainly don't
want to fight for the term. Whatever we call the passing semantics
and methods in Python... it will not change what I understand about
what happens with certain kinds of calls vs others.

cheers.

[greg]

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

Steve Holden wrote:

greg wrote:
>

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

That's an odd position to take, considering that the
Python docs use the word "assignment " all over the
place, and the language even has a statement known
as an "assignment statement".

The Python Language Reference has this to say about
assignment:

The following constructs bind names: formal parameters to functions, import
statements, class and function definitions (these bind the class or function
name in the defining block), and targets that are identifiers if occurring in
an assignment...
[http://docs.python.org/reference/executionmodel.html]

What this suggests to me is that the reason the
Language Ref talks about binding is not because there's
anything wrong with the word assignment, but because
binding is a more general term. Assignment is one way
to perform binding, but there are other things that
perform binding as well.

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.

For my part, I'm not trying to "prove myself right",
I'm trying to be helpful by clearing up what seems to
me to be a misunderstandin g about what the term
call-by-value implies. But it appears that some people
stubbornly refuse to have their misunderstandin gs
cleared up. :-)

That's how it looks from my end, anyway. No doubt from
the other end it looks like I'm the one being stubborn.
That's why I've been trying to inject some objectivity
by doing some research and finding authoritative
references to back up what I'm saying.

I'm learning things from all this, too. For example,
until recently I couldn't be sure I wasn't the only
person in the world who had thought of the idea of
defining call-by-value in terms of assignment rather
than copying. Turns out I'm not -- Backus et al, no
less, had exactly the same idea. And it seems they're
not the only ones, either -- more on that later.

--
Greg

[greg]

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

Grant Edwards wrote:

I stopped paying much attention to this thread a while ago, but
you've got to admire the persistence of somebody who soldiers
on even though Aahz, Fredrik Lund, and Steve Holden are all on
the other side of the argument...

Those people clearly know a great deal about Python,
and I respect them for that. However, that doesn't
necessarily make them authorities on programming
language terminology.

If you're going to indulge in argument by authority,
you need to pick authorities that can be considered,
er, authoritative in the field concerned...

--
Greg

[Aaron Brady]

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

On Nov 13, 3:44 am, greg <g...@cosc.cant erbury.ac.nzwro te:

Grant Edwards wrote:

I stopped paying much attention to this thread a while ago, but
you've got to admire the persistence of somebody who soldiers
on even though Aahz, Fredrik Lund, and Steve Holden are all on
the other side of the argument...

>
Those people clearly know a great deal about Python,
and I respect them for that. However, that doesn't
necessarily make them authorities on programming
language terminology.
>
If you're going to indulge in argument by authority,
you need to pick authorities that can be considered,
er, authoritative in the field concerned...

The authors of C# and Java can be considered authorities in the field
concerned. So authoritative, that if they want to redefine existing
terms, the masses must follow.

[greg]

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

Fredrik Lundh wrote:

Python's definition of the word "value" can be found in the language
reference:
>
http://docs.python.org/reference/dat...lues-and-types

That whole passage is talking almost
exclusively about the value of an *object*:

Every object has an identity, a type and a value...
...possible values for objects of that type...
The value of some objects can change...

etc. etc. But we don't want to know about the value of
an object, we want to know about the value of an
*expression*. That section doesn't tell us. Nor does
it tell us that expressions don't *have* values. It
says nothing about expressions at all.

Using that definition, a Python expression yields an object, not an
object value.

And as I've said before, that's a perfectly fine viewpoint.
Because,

An assignment statement evaluates the expression list (remember that this can
be a single expression or a comma-separated list, the latter yielding a tuple)
and assigns the single resulting object to each of the target lists, from left
to right.

[http://docs.python.org/reference/sim...signment_stmt]

and what it says about binding makes it clear that assignment
is a form of binding operation.

So it doesn't matter *what* you call the result of an expression
-- a value, an object, an object reference, or whatever -- the
differences all cancel out when you define assignment in a
corresponding way.

--
Greg

[Fredrik Lundh]

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

greg wrote:

If you're going to indulge in argument by authority,
you need to pick authorities that can be considered,
er, authoritative in the field concerned...

Like Barbara Liskov, who's won tons of awards for her work on computer
science and programming languages, and who was among the first to
design, implement, and formally describe a language with *exactly* the
same evaluation semantics as Python? What did she and her co-authors
have to say about the calling semantics in their new language? Let's see:

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

Let's take that again, with emphasis:

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

"It is not". "And it is not".

But maybe they were just ignorant, and didn't really "get" how earlier
languages worked? Let's see what Liskov has to say about that:

"The group as a whole was quite knowledgeable about languages that
existed at the time. I had used Lisp extensively and had also
programmed in Fortran and Algol 60, Steve Zilles and Craig
Schaffert had worked on PL/I compilers, and Alan Snyder had done
extensive programming in C. In addition, we were familiar with
Algol 68, EL/1, Simula 67, Pascal, SETL, and various machine
languages. Early in the design process we did a study of other
languages to see whether we should use one of them as a basis for
our work [Aiello, 1974]. We ultimately decided that none would be
suitable as a basis. None of them supported data abstraction, and
we wanted to see where that idea would lead us without having to
worry about how it might interact with pre-existing
features. However, we did borrow from existing languages. Our
semantic model is largely borrowed from Lisp; our syntax is
Algol-like."

Still think they didn't understand Algol's semantic model?

:::

But nevermind - the real WTF with threads like this one is the whole
idea that there are two and only two evaluation strategies to choose
from. That's a remarkable narrow-mindedness.

</F>

[rurpy@yahoo.com]

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

On Nov 12, 2:05 pm, Fredrik Lundh <fred...@python ware.comwrote:

Python's definition of the word "value" can be found in the language
reference:
>

http://docs.python.org/reference/datamodel.html#objects-values-and-types

>
Using that definition, a Python expression yields an object, not an
object value.

There is no definition of value there, just an assertion that values
exist.

[Terry Reedy]

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

Fredrik Lundh wrote:

greg wrote:
>

>If you're going to indulge in argument by authority,
>you need to pick authorities that can be considered,
>er, authoritative in the field concerned...

>
Like Barbara Liskov, who's won tons of awards for her work on computer
science and programming languages, and who was among the first to
design, implement, and formally describe a language with *exactly* the
same evaluation semantics as Python? What did she and her co-authors
have to say about the calling semantics in their new language? Let's see:
>
"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 reference manual. 1979 Google's searchable HTML version (apparently
from OCR of scan package as .pdf) with a few mis-conversions.

http://64.233.169.104/search?q=cache:iNQhnst06X8J:www.oberon2005.ru/doc/doc-mit1979-000225e.pdf

We call the argument passing technique call by sharing, because the
argument objects are shared between the caller and the called routine.

She later. in 1992, called it "pass by object" (below).

But maybe they were just ignorant, and didn't really "get" how earlier
languages worked? Let's see what Liskov has to say about that:
>
"The group as a whole was quite knowledgeable about languages that
existed at the time. I had used Lisp extensively and had also
programmed in Fortran and Algol 60, Steve Zilles and Craig
Schaffert had worked on PL/I compilers, and Alan Snyder had done
extensive programming in C. In addition, we were familiar with
Algol 68, EL/1, Simula 67, Pascal, SETL, and various machine
languages. Early in the design process we did a study of other
languages to see whether we should use one of them as a basis for
our work [Aiello, 1974]. We ultimately decided that none would be
suitable as a basis. None of them supported data abstraction, and
we wanted to see where that idea would lead us without having to
worry about how it might interact with pre-existing
features. However, we did borrow from existing languages. Our
semantic model is largely borrowed from Lisp; our syntax is
Algol-like."
>
Still think they didn't understand Algol's semantic model?

The second quote come from
A History of CLU, by Barbara Liskov 1992

http://publications.csail.mit.edu/lcs/pubs/pdf/MIT-LCS-TR-561.pdf

Python owes more to CLU than I realized.

"Assignment has a type-independent meaning with the heap approach;
x := e
causes x to refer to the object obtained by evaluating expression e."

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

Exactly described Python also.

"we wanted to treat built-in and user-defined types alike"

Achieved fully in 3.0. She notes a difference though: some built-in
types have literals. No user types do.

"We allow common operator symbols but these are only short forms for
what is really happening, namely a call on an operation using its full
t$o name. When the compiler encounters such a symbol, it "desugars" it
by following a simple rule: it produces t$o where t is the type of the
first argument, and o is the operation name associated with the symbol.
Thus "x + y" is desugared to "t$add(x, y)" where t is the type of x."

In CLU and Python, methods belong to the class/type rather than to the
instances (as in C++ she claims).

"""Not only is this approach simple and easy to understand, it applies
to both built-in and user-defined types uniformly. To allow sugars to be
used with a new type, the type definer need only choose the right
names for the operations. For example, to allow the use of +, he or she
names the addition operation "add." """

Also, CLU has exceptions that terminate and iterators used in for
statements.

Terry Jan Reedy

[rurpy@yahoo.com]

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

On Nov 12, 7:09 pm, George Sakkis <george.sak...@ gmail.comwrote:

On Nov 12, 4:05 pm, Fredrik Lundh <fred...@python ware.comwrote:
>

>greg 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?

>>
>Python's definition of the word "value" can be found in the language
>reference:
>>
>http://docs.python.org/reference/dat...lues-and-types

>
Quoting the relevant part:
>
"The value of some objects can change. Objects whose value can change
are said to be mutable; objects whose value is unchangeable once they
are created are called immutable."
>
Strictly speaking that's not a definition; it doesn't say what a value
is, only how it relates to objects. But regardless, according to this,
a Python value is what the rest of the world usually calls "state",

....snip...

That just pushes the question to, "what's state?" doesn't it?
Is a method part of an object's state (and hence "value"?)
Are an object's data attribute values part of it's state?

Are the values of a, b, and c different below?

a = int(1)
class myint(int): pass
b = myint(1)
c = myint(1)
c.foo = 2

I have yet to see any reasonable definition of a Python
value in the Python docs or elsewhere, despite the fact
that a value is one of the three defining characteristics
of an object, a central concept in Python.

[Terry Reedy]

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

rurpy@yahoo.com wrote:

I have yet to see any reasonable definition of a Python
value in the Python docs or elsewhere, despite the fact
that a value is one of the three defining characteristics
of an object, a central concept in Python.

I noticed too. My try:

The value of an object is the information that the object represents (or
that is stored with the object) that the interpreter uses to compute the
value of a new object when you use the object in an expression. For
number objects, the number value. For collection objects, the objects
collected. For functions, the signature and function performed when called.

How is that?

Terry Jan Reedy

[rurpy@yahoo.com]

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

On Nov 13, 4:53 pm, Terry Reedy wrote:

rurpy@yahoo.com wrote:
>

>I have yet to see any reasonable definition of a Python
>value in the Python docs or elsewhere, despite the fact
>that a value is one of the three defining characteristics
>of an object, a central concept in Python.

>
I noticed too. My try:
>
The value of an object is the information that the object represents (or
that is stored with the object) that the interpreter uses to compute the
value of a new object when you use the object in an expression. For
number objects, the number value. For collection objects, the objects
collected. For functions, the signature and function performed when called.
>
How is that?

I am starting with the idea that "value" is what we call
whatever it is that is the difference between, for example,
the objects int(3) and int(4). While your definition
seems to be saying something similar it does not seem
very precise.

How would I use your definition to answer the following
questions?

* How does an object get a value?

* Can I create an object that has a value that
is the same as int(3) without somehow using an
int(3) object in its construction?

* Do all objects have values? (Ignore the Python
docs if necessary.)

* What is the value of object()?

* Does an object's behavior (methods) affect
its value?

* If two objects have different unrelated types
(i.e. not subclassed), are their values necessarily
different (regardless of how they print, or act
when used in an expression)?

* What if they aren't unrelated but one is a sub-
class of the other?

* Can one completely hide an object's value by
overriding methods?

* Can two objects have the same value, even if the
methods of one have been overridden to hide it's
value as completely as possible?

I wonder if all values come, directly or indirectly,
from "valued objects" created in the C-API?
Or perhaps value is some sort of useful but fundamentally
undefinable concept that disappears when looked at too
closely, leaving behind only state and behavior?