Finding the instance reference of an object

S

Steve Holden

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!!(BThat'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.
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
 
A

Aaron Brady

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.
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'?
 
G

greg

Antoon said:
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.
 
D

Douglas Alan

Joe Strout said:
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
 
A

Aaron Brady

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

Steven D'Aprano

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

Steven D'Aprano

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

Steven D'Aprano

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

John Nagle

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




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
 
A

Aaron Brady

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

Aaron Brady

Aaron Brady said:
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:

Well, the docs don't take my side either.

"object.__setitem__(self, key, value)
Called to implement assignment to self[key]."

But wait, is that true assignment?

"Assignment statements
Assignment statements are used to (re)bind names to values and to
modify attributes or items of mutable objects:"

"If the target is an identifier (name):
.... the name is bound to the object in the current global namespace."

The latter is the case of interest.
 
G

greg

Aaron said:
But wait, is that true assignment?

It's assignment, but it's not really copying an object. No new
objects are being created -- rather, some of the items within
the lhs object are being rebound to already-existing objects.

It would be possible for the lhs object's __setitem__ method
to be defined so that it created new objects, but then it
would be the __setitem__ method doing that, not the assignment
statement itself.

None of this is really relevant anyway, since the assignment
that call-by-value implies is always to a bare local name, and
there is no way that kind of assignment can ever create a new
object.
 
G

greg

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

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

The same thing as would happen if you wrote

std::vector said:
what happens during a call to the following Python
function?

def f( x ): ...

The same thing as would happen if you wrote

x = actual_parameter_expression
If not, which one is call-by-value?

They're both call-by-value, because they're both equivalent to
assignment according to the rules of the language concerned.

Whether they're "the same" depends on what you mean by "same".
If you define "same" in such a way that they're not, then that
definition of "same" is irrelevant to the matter at hand.
 
G

greg

Steven said:
You've just *assumed* that assignment in Algol 60 doesn't involving
copying.

I've done no such thing. I've *refrained* from assuming that
the "assignment" in the definition always has to refer to
Algol 60 assignment. You're the one insisting on tying
everything to Algol.

I don't know whether the Algol committee had such a general
meaning in mind when they wrote that document. It's quite
likely they weren't thinking that far ahead. But the fact is
that it *can* be generalized to other languages in an
obvious and useful way, and many language designers after
them have generalized it in exactly that way.
Ah crap, I meant *Pascal*.

Not in plain Pascal, but Apple's Object Pascal (and probably
other OO Pascal dialects) have object types that are implicitly
referred to by pointers, like Python objects -- and when you
pass one by value, only the pointer is copied, not the whole
object.
 
A

Aaron Brady

The same thing as would happen if you wrote




The same thing as would happen if you wrote

   x = actual_parameter_expression


They're both call-by-value, because they're both equivalent to
assignment according to the rules of the language concerned.

No, you have described call-by-equals-sign, or call-by-assignment.
While call-by-assignment and call-by-value are equivalent in C++, that
does not make your rule hold for all languages. Python is call-by-
assignment too, as well as call-by-sharing. Just because a language
is call-by-assignment, is not sufficient (or necessary) to be call-by-
value. Call-by-value has other characteristics that Python does not
meet.
 
G

greg

Aaron said:
Call-by-value has other characteristics that Python does not
meet.

The designers of most other dynamic languages don't
seem to share that opinion, since they use the term
call-by-value just as though it *does* mean call-
by-assignment and nothing more.
 
A

Aaron Brady

The designers of most other dynamic languages don't
seem to share that opinion, since they use the term
call-by-value just as though it *does* mean call-
by-assignment and nothing more.

The experts are divided. There is no science that tells you how to
extrapolate a term, such as say, the Japanese equivalent of meat &
potatoes or apple pie, or c-b-v into a language that doesn't have a
copy constructor. Furthermore, to apply c-b-v to Python, you have to
introduce the concept of pointers, which is ostensibly non-native for
human programmers. You'd have a pretty hard time making the case that
c-b-v is 'round peg, round hole' for Python. Just describe it and
give it a name.
 
J

Joe Strout

Furthermore, to apply c-b-v to Python, you have to
introduce the concept of pointers, which is ostensibly non-native for
human programmers.

Not necessarily "pointers" per se -- any type of object references
will do, and yes, Python has those in spades.
You'd have a pretty hard time making the case that c-b-v is 'round
peg, round hole' for Python.

I didn't find it all that hard: <http://www.strout.net/info/coding/valref/
Just describe it and give it a name.

OK: "Python variables contain object references, which are copied from
the actual parameter expression to the formal parameter. This
evaluation strategy is named 'call-by-value,' though some authors use
the term 'call-by-sharing' to indicate the specific case of call-by-
value where the values passed are object references."

(I should add that last bit to my web page -- I'll try to do that this
weekend.)

Cheers,
- Joe

P.S. I've pretty well tired of this thread, but I can't let Greg stand
up for truth and clarity all by himself...
 
A

Aaron Brady

Not necessarily "pointers" per se -- any type of object references  
will do, and yes, Python has those in spades.

Humans don't. That's my point.

A cut and paste into my editor counts 2,563 words on your link. Does
2,563 words classify as 'round peg, round hole' in your world?
OK: "Python variables contain object references, which are copied from  
the actual parameter expression to the formal parameter.  This  
evaluation strategy is named 'call-by-value,' though some authors use  
the term 'call-by-sharing' to indicate the specific case of call-by-
value where the values passed are object references."

Better: Objects are passed to functions without copying, and
assignment assigns a new identity to the variable, without changing
the old object. Round peg, round hole.

The only purpose it serves to keep bringing up reference this and
reference that, is so you can 'square peg, round hole' the term 'call-
by-value'.
(I should add that last bit to my web page -- I'll try to do that this  
weekend.)

What you should do, is add mine to the 'short answer' section, and
yours to the 'long answer' section. Diversify your portfolio.
P.S. I've pretty well tired of this thread, but I can't let Greg stand  
up for truth and clarity all by himself...

Truth and clarity are not tired of this thread.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top