Finding the instance reference of an object

[Douglas Alan]

Re: Finding the instance reference of an object

greg <greg@cosc.cant erbury.ac.nzwri tes:

Steven D'Aprano wrote:

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

Personally, I find this whole debate kind of silly, as it is based on
a completely fallacious either/or dichotomy.

(1) It is unarguably true that Python and Java use a type of
call-by-value. This follows from the standard definition of
call-by-value, and common usage in, for example, the Scheme and
Java communities, etc.

(2) It is also unarguably true that saying that Python or Java use
"call-by-value", and saying nothing more is going to be profoundly
confusing to anyone who is learning these languages.

It's like the difference between

Q. What is a giraffe?

A. A giraffe is a type of animal.

and

Q. What is Greg?

A. Greg is a type of animal.

In both cases, the answers are strictly correct, but in the second
case, the answer is also deeply misleading.

Q. How do we generally solve this problem when speaking?

A. We invent more specific terms and then generally stick to the more
specific terms when the more general terms would be misleading.

I.e.,

Q. What is Greg?

A. Greg is a human being.

and

Q. What type of calling semantics do Python and Java use?

A. Call-by-sharing.

I assert that anyone who does not understand all of the above, is
helping to spread confusion.

|>oug

[Joe Strout]

Re: Finding the instance reference of an object

On Nov 19, 2008, at 11:05 AM, Douglas Alan wrote:

Personally, I find this whole debate kind of silly, as it is based on
a completely fallacious either/or dichotomy.
>
(1) It is unarguably true that Python and Java use a type of
call-by-value. This follows from the standard definition of
call-by-value, and common usage in, for example, the Scheme and
Java communities, etc.

True.

(2) It is also unarguably true that saying that Python or Java use
"call-by-value", and saying nothing more is going to be profoundly
confusing to anyone who is learning these languages.

Perhaps (unless they've already learned this from one of the other
languages).

Q. How do we generally solve this problem when speaking?
>
A. We invent more specific terms and then generally stick to the more
specific terms when the more general terms would be misleading.
>
I.e.,
>
Q. What is Greg?
>
A. Greg is a human being.
>
and
>
Q. What type of calling semantics do Python and Java use?
>
A. Call-by-sharing.

Fair enough, but if the questioner then says "WTF is call-by-sharing,"
we should answer "call-by-sharing is the term we prefer for call-by-
value in the case where the value is an object reference (as is always
the case in Python)."

I assert that anyone who does not understand all of the above, is
helping to spread confusion.

I agree.

Best,
- Joe

[Craig Allen]

Re: Finding the instance reference of an object

I've just come to the conclusion it's not possible to call functions
in python, to do so is undefined and indeterminate, like dividing by
zero. Henceforth no calling functions for me as clearly it's the
devil's playground.

[Steve Holden]

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

rurpy@yahoo.com wrote:

On Nov 18, 10:22 am, Steve Holden <st...@holdenwe b.comwrote
in thread "Python-URL! weekly Python news and links (Nov 17)":

>rurpy@yahoo.com wrote:
>[...]

>>One of the reasons I would like to formulate a good
>>model of an object's value and type is so that I could
>>try to offer something better. Responses like yours
>>are significantly demotivating.

>And yet you argue when people try to explain to you that objects don't
>*have* values, objects *are* values. Objects have attributes, which are
>references to other values. One of an object's attributes is its type.

>
I am sorry for arguing with you. I hear you
and others saying that the value (in the english
language sense of value) of an object *is* the
object.
>

That's OK. I don't assume you are arguing to be difficult, but to cast
light on a dark area.

But before I address that, I am a little confused
by what you wrote above. Quoting the PLR again,
"Every object has an identity, a type and a value."
I presumed "value" to include attributes. Are you
saying the correct statement in the PLR should have
been, "Every object has an identity, attributes, and
a value"?
>
The text below refers to identity, type and value
per the PLR, but you can substitute "attributes "
for type without affecting the logic.
>
Here is why I am having trouble accepting the
explanations you and others have kindly offered
me. If values are objects then the words "object"
and "value" are synonymous, yes? Fine, I can see
that could be a desirable thing. Value is more
natural than object for people coming to Python,
for example.
>
But if you use the word value synonymously with
object, then the PLR statement that "an object
has identity, type, and value" is the same as "an
object has identity, type, and itself". We know
the object is itself!$B!!(B That's tautological. So
what is the point of using the term value in the
definition of "object"? You can just say "an object
has identity and type, and we will also use the word
value as a synonmym for object."
>
Other than cosmetics, the word "value" serves no
purpose and we can replace it with "object" wherever
we use it. E.g. "the result of evaluating an
expression is a value.", "the result of evaluating
an expression is an object". If value is the same
as object, then Python objects have only identity
and type.
>
But you know that's not true. The types of int(2)
and int(3) are the same. Is the difference in
behavior of the two objects due to their different
identities?! Python knows the object at 0x260FF44
is a "2" object, and the object at 0x260FD60 is a
"3" solely by virtue of their addresses?
>
Of course not.
I hope you see why I find the "value is object"
to be an unacceptable explanation of Python
objects.
>

I now understand where your confusion arises, and I also have to accept
that integer types have a value that isn't formally available as an
attribute.

However, I don't personally see the need to go beyond the Python object
"2", since operations involving that value are not programmed in Python
but in the underlying implementation language.

>You seem to be hunting for the ineffable
>"primitive value" that has no other attributes.
>Such a thing doesn't exist.

>
Sorry to argue again, but I explained (in a
previous post) why I believe such a thing does
exist. Specifically, it is necessary to explain
the difference between the objects int(2) and
int(3). Perhaps if you tell me exactly what
fault you find with that previous explanation
(in light of my problem with "values are objects"
above), I could reevaluate my understanding.

I suppose I was thinking more of the compound values than the primitive
immutable type instances. I take your point that int(3) and int(2) do
indeed differ by virtue of having different values for some "hidden
attribute" that isn't available to the Python programmer.

Since the differences aren't directly addressable in Python, however, I
prefer to ignore them :)

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

[Aaron Brady]

Re: Finding the instance reference of an object

On Nov 19, 12:28 pm, Joe Strout <j...@strout.ne twrote:

On Nov 19, 2008, at 11:05 AM, Douglas Alan wrote:

(2) It is also unarguably true that saying that Python or Java use
   "call-by-value", and saying nothing more is going to be profoundly
   confusing to anyone who is learning these languages.

>
Perhaps (unless they've already learned this from one of the other  
languages).

If they learn the bad definition first, we can't go back and change
it. We can correct it for them for the future. Don't appeal to hot-
shot authorities, like the ones that don't acknowledge that there were
already people using terms they hijacked for their own cult following.

  Q. What type of calling semantics do Python and Java use?

>

  A. Call-by-sharing.

>
Fair enough, but if the questioner then says "WTF is call-by-sharing,"  
we should answer "call-by-sharing is the term we prefer for call-by-
value in the case where the value is an object reference (as is always  
the case in Python)."

But if someone says, 'What is call-by-reference?', do you answer, 'C-b-
r is the term we prefer for call-by-value in the case where the value
is a variable reference'?

[greg]

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

Antoon Pardon wrote:

You are changing your argument. In a follow up you
made the point that call by value should be as it
was intended by the writers of the algol 60 report.

No, I was countering the argument that "call by value"
is short for "call by copying the value". I was pointing
out that the inventors of the term didn't use any such
words.

Arguing that their words were intended to imply copying,
as part of the essence of the idea, is making an even
bigger assumption about their intentions, IMO.

Rather it seems to me that the essence of the idea they
had in mind is that call-by-value is equivalent to
assignment.

Furthermore, I don't seem to be alone in coming to that
conclusion -- the designers of other dynamic languages
appear to be using the same logic when they describe
their parameter passing as call-by-value.

Here's an example from "The SNOBOL Programming Language",
2nd Edition, by R. E. Griswold, J. F. Poage and I. P.
Polonsky. On p. 15:

Arguments are passed by value and may be arbitrarily
complex expressions.

and later on p. 95:

When a call to a programmer-defined function is made, the
arguments to the call are evaluated first. Before execution
of the procedure begins ... new values are assigned to these
variables as follows: ... (2) the formal arguments are
assigned their values.

--
Greg

[Douglas Alan]

Re: Finding the instance reference of an object

Joe Strout <joe@strout.net writes:

> Q. What type of calling semantics do Python and Java use?
>>
> A. Call-by-sharing.

>
Fair enough, but if the questioner then says "WTF is call-by-sharing,"
we should answer "call-by-sharing is the term we prefer for call-by-
value in the case where the value is an object reference (as is always
the case in Python)."

Personally, I think that it is much preferable to leave
"call-by-value" completely out of any such discussion, as it provably
leads to a great deal of confusion and endless, pointless debate.
It's better to just start from a clean slate and explain how
call-by-sharing works, and to assert that it is quite different from
the calling semantics of languages such as C or Pascal or Fortran, so
the student must set aside any preconceptions about how argument
passing works.

Call-by-sharing is technically a type of call-by-value only for those
who are devotees of academic programming language zoology. For
everyone else, call-by-sharing is its own beast. One might point all
of this out in the discussion, however, if it will help the other
person understand. You never know -- they might be a fan of academic
programming zoology.

|>oug

[Aaron Brady]

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

On Nov 19, 7:22 pm, greg <g...@cosc.cant erbury.ac.nzwro te:

Antoon Pardon wrote:

You are changing your argument. In a follow up you
made the point that call by value should be as it
was intended by the writers of the algol 60 report.

>
No, I was countering the argument that "call by value"
is short for "call by copying the value". I was pointing
out that the inventors of the term didn't use any such
words.
>
Arguing that their words were intended to imply copying,
as part of the essence of the idea, is making an even
bigger assumption about their intentions, IMO.
>
Rather it seems to me that the essence of the idea they
had in mind is that call-by-value is equivalent to
assignment.
>
Furthermore, I don't seem to be alone in coming to that
conclusion -- the designers of other dynamic languages
appear to be using the same logic when they describe
their parameter passing as call-by-value.
>
Here's an example from "The SNOBOL Programming Language",
2nd Edition, by R. E. Griswold, J. F. Poage and I. P.
Polonsky. On p. 15:
>
   Arguments are passed by value and may be arbitrarily
   complex expressions.
>
and later on p. 95:
>
   When a call to a programmer-defined function is made, the
   arguments to the call are evaluated first. Before execution
   of the procedure begins ... new values are assigned to these
   variables as follows: ... (2) the formal arguments are
   assigned their values.

Tell me, what happens during a call to the following C++ function?

void f( std::vector< int x );

Is it the same as what happens during a call to the following Python
function?

def f( x ): ...

If not, which one is call-by-value?

[Steven D'Aprano]

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

On Thu, 20 Nov 2008 14:22:50 +1300, greg wrote:

Antoon Pardon wrote:
>

>You are changing your argument. In a follow up you made the point that
>call by value should be as it was intended by the writers of the algol
>60 report.

>
No, I was countering the argument that "call by value" is short for
"call by copying the value". I was pointing out that the inventors of
the term didn't use any such words.

Nor did they define what assignment means, and their definition of
"value" seems to exclude such things as strings.

Arguing that their words were intended to imply copying, as part of the
essence of the idea, is making an even bigger assumption about their
intentions, IMO.
>
Rather it seems to me that the essence of the idea they had in mind is
that call-by-value is equivalent to assignment.

You've just *assumed* that assignment in Algol 60 doesn't involving
copying. Based on the very little I know about Algol, I think that is a
very unsafe assumption. I know significantly more about Pascal, and in
Pascal, assignment *is* copying.

(I wait now with bated breath for somebody to point out some Python
implementation or feature where assignment doesn't make a copy...)



--
Steven

[Steven D'Aprano]

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

On Wed, 19 Nov 2008 11:20:05 -0500, Terry Reedy wrote:

>It is useful and convenient to have "null values" like None, but it
>isn't useful to say that None is not a value.

>
I never said that.

But you've been defending the views of somebody who did. If you're going
to play Devil's Advocate for views you don't believe (and I've been known
to do the same myself), make it clear that this is what you're doing --
or at least don't take criticisms of those views as attacks against you.

I said that it has no attributes (other than
__class__) and no private data. In other words, no content, no state.
It is an empty object, just like objects()s, and similar in that to
empty collections.

Yes, but the lack of state is itself a state, just like 0 is still an int
despite being the lack of quantity. That's the point I'm trying to make:
having no state is itself a state, just like the empty set is a set.
Because of its particular state ("empty state") None has behaviour
different from most other objects, in the same way that 0 behaves
differently from other ints (e.g. a*x==x for all values of a only if
x==0). But singling None out as "not a value" is just like singling 0 as
as not an int.


--
Steven

[John Nagle]

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

Steven D'Aprano wrote:

On Thu, 20 Nov 2008 14:22:50 +1300, greg wrote:
>

>Antoon Pardon wrote:
>>

>>You are changing your argument. In a follow up you made the point that
>>call by value should be as it was intended by the writers of the algol
>>60 report.

>No, I was countering the argument that "call by value" is short for
>"call by copying the value". I was pointing out that the inventors of
>the term didn't use any such words.

>
Nor did they define what assignment means, and their definition of
"value" seems to exclude such things as strings.
>
>
>

>Arguing that their words were intended to imply copying, as part of the
>essence of the idea, is making an even bigger assumption about their
>intentions, IMO.
>>
>Rather it seems to me that the essence of the idea they had in mind is
>that call-by-value is equivalent to assignment.

>
You've just *assumed* that assignment in Algol 60 doesn't involving
copying. Based on the very little I know about Algol, I think that is a
very unsafe assumption. I know significantly more about Pascal, and in
Pascal, assignment *is* copying.
>
(I wait now with bated breath for somebody to point out some Python
implementation or feature where assignment doesn't make a copy...)

In stock ALGOL-60, there are only the primitive types, and assignment
of them is a copy. Most useful implementations had strings, and Simula,
which was an ALGOL extension, had objects.

Simula had value parameters, reference parameter, and name parameters.
For assignment, ":=" specified a value assignment, and ":-" specified
a reference assignment.

John Nagle

[Steven D'Aprano]

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

On Fri, 21 Nov 2008 03:32:25 +0000, Steven D'Aprano wrote:

>Rather it seems to me that the essence of the idea they had in mind is
>that call-by-value is equivalent to assignment.

>
You've just *assumed* that assignment in Algol 60 doesn't involving
copying. Based on the very little I know about Algol, I think that is a
very unsafe assumption. I know significantly more about Pascal, and in
Pascal, assignment *is* copying.
>
(I wait now with bated breath for somebody to point out some Python
implementation or feature where assignment doesn't make a copy...)

Ah crap, I meant *Pascal*. Python of course doesn't copy objects when you
assign them.


--
Steven

[Duncan Booth]

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

Steven D'Aprano <steve@REMOVE-THIS-cybersource.com .auwrote:

On Fri, 21 Nov 2008 03:32:25 +0000, Steven D'Aprano wrote:
>

>>Rather it seems to me that the essence of the idea they had in mind
>>is that call-by-value is equivalent to assignment.

>>
>You've just *assumed* that assignment in Algol 60 doesn't involving
>copying. Based on the very little I know about Algol, I think that is
>a very unsafe assumption. I know significantly more about Pascal, and
>in Pascal, assignment *is* copying.
>>
>(I wait now with bated breath for somebody to point out some Python
>implementati on or feature where assignment doesn't make a copy...)

>
Ah crap, I meant *Pascal*. Python of course doesn't copy objects when
you assign them.
>
>

I think you meant "Python of course doesn't copy objects when you rebind
names". Python can (and sometimes does) make copies of objects when you
assign them, , but only if the assignment involves something other than
simply rebinding a name. e.g.

a[:] = [1, 2, 3]



--
Duncan Booth http://kupuguy.blogspot.com

[Aaron Brady]

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

On Nov 21, 3:11 am, Duncan Booth <duncan.bo...@i nvalid.invalidw rote:

Steven D'Aprano <st...@REMOVE-THIS-cybersource.com .auwrote:

On Fri, 21 Nov 2008 03:32:25 +0000, Steven D'Aprano wrote:

>

>Rather it seems to me that the essence of the idea they had in mind
>is that call-by-value is equivalent to assignment.

>

You've just *assumed* that assignment in Algol 60 doesn't involving
copying. Based on the very little I know about Algol, I think that is
a very unsafe assumption. I know significantly more about Pascal, and
in Pascal, assignment *is* copying.

>

(I wait now with bated breath for somebody to point out some Python
implementation or feature where assignment doesn't make a copy...)

>

Ah crap, I meant *Pascal*. Python of course doesn't copy objects when
you assign them.

>
I think you meant "Python of course doesn't copy objects when you rebind
names". Python can (and sometimes does) make copies of objects when you
assign them, , but only if the assignment involves something other than
simply rebinding a name. e.g.
>
a[:] = [1, 2, 3]

No, that's not assignment, it's syntactic sugar for a __setslice__
call. No copies here.

[Duncan Booth]

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

Aaron Brady <castironpi@gma il.comwrote:

>a[:] = [1, 2, 3]

>
No, that's not assignment, it's syntactic sugar for a __setslice__
call. No copies here.
>

Oh dear, perhaps you had better get the Python developers to update the
grammar that Python uses as that seems to think it's an assignment:

assignment_stmt ::= (target_list "=")+ (expression_lis t |
yield_expressio n)
target_list ::= target ("," target)* [","]
target ::= identifier
| "(" target_list ")"
| "[" target_list "]"
| attributeref
| subscription
| slicing


:^)

--
Duncan Booth http://kupuguy.blogspot.com