Finding the instance reference of an object

[Steven D'Aprano]

Re: Official definition of call-by-value (Re: Finding theinstancerefe rence...)

On Mon, 17 Nov 2008 22:08:04 +0200, Hendrik van Rooyen wrote:

And here one is faced with the same problem as I pointed to above - if
you do not have access to the struct definition (which you don't have at
run time), its kind of difficult to figure out where the value is, and
you can only access it via the public methods supplied, if any.

Asking *where* the value is is a completely different question to asking
*what* the value is.

I demonstrated that earlier in this thread, where I implemented the
beginnings of an int-class using unary notation, using a linked list. The
value of the object was encoded by the length of the chain of objects, so
there was no "where" that value was stored. It was distributed over the
entire linked list.


--
Steven

[Antoon Pardon]

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

On 2008-11-12, 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
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.

Call by value is officially defined in terms of assignment in
a context where assignments means copying and in a definition
of a specifix language.

You can't lift this part out of the definition of algol 60
and say it applies equally well in languages with different
assignment semantics.

If call by value is defined in terms of assignment regardless
of what the semantics of the assignment is then IMO call by
value is rather useless term and it would be better to talk
about call by copy in the case of C, to make sure one understands
the difference between what happens in C and what happens in
other languages that also have "call by assignment" but behave
very differently.

--
Antoon Pardon

[Aaron Brady]

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

On Nov 18, 2:21 am, Antoon Pardon <apar...@forel. vub.ac.bewrote:

On 2008-11-12, greg <g...@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 quotedin 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.

>
Call by value is officially defined in terms of assignment in
a context where assignments means copying and in a definition
of a specifix language.
>
You can't lift this part out of the definition of algol 60
and say it applies equally well in languages with different
assignment semantics.
>
If call by value is defined in terms of assignment regardless
of what the semantics of the assignment is then IMO call by
value is rather useless term and it would be better to talk
about call by copy in the case of C, to make sure one understands
the difference between what happens in C and what happens in
other languages that also have "call by assignment" but behave
very differently.
>
--
Antoon Pardon

I think Joe's argument was, C and Python can both be call-by-value, so
long as Python variables are construed to be pointers. To him,
pointers are easy to understand, even for novices, and the copy
constructor for pointers is trivial.

Otherwise, C and Algol have different definitions of call-by-value,
and while Java might be Algol-call-by-value, Python is not C call-by-
value. So, between C and Algol has majority and which has seniority
claim to the term?

[Antoon Pardon]

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

On 2008-11-12, greg <greg@cosc.cant erbury.ac.nzwro te:

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.

But you didn't try to find out their intention. You just took their
words and applied it in a different context. It isn't at all obvious
that placing their words in a context with different assignment
semantics would preserve their intend.

--
Antoon Pardon

[Steve Holden]

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

Steven D'Aprano wrote:

On Mon, 17 Nov 2008 18:35:04 -0800, Craig Allen wrote:
>

>>>>* Do all objects have values? (Ignore the Python
>>>> docs if necessary.)
>>>If one allows null values, I am current thinking yes.
>>I don't see a difference between a "null value" and not having a value.
>>>
>>>

>I think the difference is concrete... an uninitialized variable in C has
>no value, I'd say, because the value it will have is indeterminate, it
>will be whatever happens to be sitting at that location in memory,
>inconsistent . If that variable is initialized to some value
>representing "none", like NULL, then it has a consistent value of
>"none". There is no way to have an uninitialized variable in python, so
>they are always consistently set, so they always have values.
>>
>?

>
Well said.
>
I'd even go so far as to say that an uninitialized variable in C has a
random value, unless the compiler prevents you from accessing it. If the
compiler lets you (accidentally, I assume!) do something with an
uninitialized variable, then you're accessing whatever random value it
happens to get.
>
>

I think the correct terminology would be "the value of the variable is
undefined", meaning that each implementation is free to use whatever
behavior it likes.

Most C implementations will (I believe) end up with random data in those
variables rather than taking the time to initialize them to some
recognizable value (although some implementations have done that), and
this can be a fruitful source of non-repeatable segmentation faults and
inexplicable behaviors.

The nice thing about Python's ability to create variables on assignment
is that you will either get an UnboundLocalErr or or a NameError or an
AttributeError exception if you try to access a name that hasn't been
defined. This nicely parallels KeyError and IndexError behavior with
container objects.

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

[rurpy@yahoo.com]

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

On Nov 17, 7:35 pm, Craig Allen <callen...@gmai l.comwrote:

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

>>

If one allows null values, I am current thinking yes.

>>
>I don't see a difference between a "null value"
>and not having a value.

>
I think the difference is concrete... an uninitialized variable in C
has no value, I'd say, because the value it will have is
indeterminate, it will be whatever happens to be sitting at that
location in memory, inconsistent. If that variable is initialized to
some value representing "none", like NULL, then it has a consistent
value of "none". There is no way to have an uninitialized variable in
python, so they are always consistently set, so they always have
values.

I wrote "I don't see a difference between a "null value"
and not having a value" in the specific context of "what
constitutes an object?" considering the Python Docs
definition of object as identity, type, and value. It
was that "value" (the characteristic of an object that
is left after you have considered id and type), that I
was referring to. I still see no difference between a
"null value" and "has no value" in that context.
Nothing (directly) to do with memory, variables, C,
parameter passing, None, etc.

I realize in hightsight that the word "value" is too strongly
overloaded with pre-existing semantics for many people to
accept it being redefined with a specific meaning in the
limited context of a description of Python objects. And it
was also pretty dumb of me to raise the issue in a contentious
thread about values in parameter passing. Live and learn....

[Terry Reedy]

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

Steven D'Aprano wrote:

On Sun, 16 Nov 2008 15:46:54 -0800, rurpy wrote:

For example, consider the two electrons around a helium nucleus. They
have the same mass, the same speed, the same spin, the same electric
charge, the same magnetic moment, they even have the same location in
space (technically, the same wave function).

By quantum mechanics (Pauli Exclusion principle), this is impossible.

They are identical in every
possible way. Are they the same electron, or two different electrons?
What does the question even mean?

That you do not understand QM?

Photons, on the other hand, can be identical, hence lasars.

Matter is divided into leptons and bosons, individualists and
communalists. (I believe I have the name right.)

>For example, you can define the value of None however you want, but it
>seems clear that it has (and needs) no intrinsic-value.

>
To me, that seems just as silly as arguing that zero is not a number,

To me, that distortion of his (and my) point is silly. 0 partipipates
in numerous integer operations, whereas None participates in no NoneType
operations. (Neither has attributes.) And that is the difference he is
pointing at.

or that white pixels are "nothing" and black pixels are "something" .

This is a ridiculous attempt at ridicule;-) Pixels have positions and 1
to 4 graded attributes. Completely different from None.

tjr

[Robert Kern]

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

Terry Reedy wrote:

Steven D'Aprano wrote:

>On Sun, 16 Nov 2008 15:46:54 -0800, rurpy wrote:

>

>For example, consider the two electrons around a helium nucleus. They
>have the same mass, the same speed, the same spin, the same electric
>charge, the same magnetic moment, they even have the same location in
>space (technically, the same wave function).

>
By quantum mechanics (Pauli Exclusion principle), this is impossible.
>

They are identical in every
>possible way. Are they the same electron, or two different electrons?
>What does the question even mean?

>
That you do not understand QM?
>
Photons, on the other hand, can be identical, hence lasars.
>
Matter is divided into leptons and bosons, individualists and
communalists. (I believe I have the name right.)

Fermions and bosons, actually.

--
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
that is made terrible by our own mad attempt to interpret it as though it had
an underlying truth."
-- Umberto Eco

[Aaron Brady]

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

On Nov 18, 2:55 pm, Terry Reedy <tjre...@udel.e duwrote:

Steven D'Aprano wrote:

On Sun, 16 Nov 2008 15:46:54 -0800, rurpy wrote:
For example, consider the two electrons around a helium nucleus. They
have the same mass, the same speed, the same spin, the same electric
charge, the same magnetic moment, they even have the same location in
space (technically, the same wave function).
or that white pixels are "nothing" and black pixels are "something" .

>
This is a ridiculous attempt at ridicule;-)  Pixels have positions and 1
to 4 graded attributes.  Completely different from None.

IINM if I'm not mistaken, portions of the retina are most excited in
the dark.

Same means one of two things. Either share an identity (continuity of
form), or high degree of similarity in structure and composition.

On a physical level, the electrical states of bit circuits in memory
are very similar in two "equal" bytes. Low voltage, low voltage, high
voltage.

Outside of the physical, the ideal, there is still such thing as
continuity. We have a memory:

M= { 0: [ 1, 2 ],
1: [ 1, 2 ] }

We can write an operation 'app( M, id, val )', which returns the
memory with the entry at id 'id' appended by 'val'. The bracket
operation ( M[ id ] ) returns the entry of the memory at id 'id'.

>>app( { 0: [ 1, 2 ], 1: [ 1, 2 ] }, 0, 3 )

{ 0: [ 1, 2, 3 ],
1: [ 1, 2 ] }

>>_[ 0 ]

[ 1, 2, 3 ]

Immutable types don't even need it. Identity serves no additional
purpose to value. That is, you can pick either tuple ( 1, 2 ), ( 1,
2 ) out of a bag with both in it, and operate.

With side-effects come mutable types, and identity and value diverge.
I think you can make a case that type is an entry in value, leaving
identity and value in general. Then, identity just means, what
original expression an object is continuous with, and value is the
original expression plus subsequent mutations.

Logical matter can be created and destroyed, which clarifies some of
the issues about composition and identity.

Now go away, before I taunt you a second time.

[greg]

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

Antoon Pardon wrote:

Call by value is officially defined in terms of assignment in
a context where assignments means copying and in a definition
of a specifix language.
>
You can't lift this part out of the definition of algol 60
and say it applies equally well in languages with different
assignment semantics.

But many other language designers, of both static and
dynamic languages, have done just that.

I'm not saying it *has* to be interpreted that way,
just that it *is* very often interpreted that way.
So you can't claim that it's not common usage.

If call by value is defined in terms of assignment regardless
of what the semantics of the assignment is then IMO call by
value is rather useless term

Not at all. It very concisely conveys how parameters
are passed, once you know how assignment works -- and
you need to understand that in any case.

--
Greg

[rurpy@yahoo.com]

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

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.

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.

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.

[Steven D'Aprano]

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

On Tue, 18 Nov 2008 15:55:10 -0500, Terry Reedy wrote:

Steven D'Aprano wrote:

>On Sun, 16 Nov 2008 15:46:54 -0800, rurpy wrote:

>

>For example, consider the two electrons around a helium nucleus. They
>have the same mass, the same speed, the same spin, the same electric
>charge, the same magnetic moment, they even have the same location in
>space (technically, the same wave function).

>
By quantum mechanics (Pauli Exclusion principle), this is impossible.

Ah yes, you're right. Oops.

However, my point remains if you consider electrons in two atoms, and
remove the "same location in space".

[...]

>>For example, you can define the value of None however you want, but it
>>seems clear that it has (and needs) no intrinsic-value.

>>
>To me, that seems just as silly as arguing that zero is not a number,

>
To me, that distortion of his (and my) point is silly. 0 partipipates
in numerous integer operations, whereas None participates in no NoneType
operations. (Neither has attributes.) And that is the difference he is
pointing at.

Why do you care about built-in NoneType operations? Why don't we count
the infinite number of useful operations we can do to None that merely
happen to not be built-in to the type?

We can convert None to a bool: bool(None)
We can append it to a list: alist.append(No ne)
We can convert it to a string: str(None), repr(None)
(In Python 2.6) We can ask how many bytes the None object uses.
We can ask the garbage collector how many objects refer to it:
gc.get_referrer s
We can count how many words have been written debating whether or not
None is a value.

and so forth. These operations aren't methods on NoneType but that is not
of any importance. The richness or poverty of methods in a class is
irrelevant.

(I trust that nobody is going to raise yet another irrelevant detail and
argue that since None is immutable, these operations don't actually do
anything *to* None. Ints are immutable too, and nobody argues that int(5)
has no value because operations on it don't do anything to it.)

It is useful and convenient to have "null values" like None, but it isn't
useful to say that None is not a value. What does it gain you, other than
losing the useful ability to say "the value of x is None"?



--
Steven

[Gabriel Genellina]

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

En Wed, 19 Nov 2008 01:14:28 -0200, <rurpy@yahoo.co mescribió:

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

I'll try to avoid any confusion here. I cannot say what defines a Python
object in a generic way, but I do know what defines a CPython object. That
is, I can talk about the current C implementation.
In CPython, an object is a C struct: PyObject. No more, no less. Most
functions in the CPython API receive, return, or handle PyObject pointers
everywhere. Every object in CPython is represented as a PyObject instance,
and has the following properties:

- An object has *identity*: its memory address, immovable, fixed once the
object is allocated.
- An object has a *type*: its ob_type field (a pointer to the type
object). The type is uniquely defined - no type inference is ever done. It
may be changed after the object was created but only if several
prerequisites are met.
- An object has *state* [or value]: everything else stored in the struct.

The PyObject struct is very small and contains nothing apart from the
ob_type field [1]. So a PyObject instance has no state, there is nothing
more defining it. A PyObject instance just "is": it has only identity and
type, it does not carry any state.

More useful objects are built by extending the PyObject struct at the end
- that is, adding more and more fields. By example, a PyIntObject adds a C
"long" field. That new field is the only difference between a PyIntObject
and a bare PyObject. We can say that a PyIntObject gained some "state":
the integer stored inside that field; some people would like to say "its
value". So, to describe completely a PyIntObject, one has to tell -in
addition to its type and identity- *which* number it contains.

More complex objects are built using the same principle: by example, a
PyFunctionObjec t contains nine more fields (func_code, func_doc, etc.) in
addition to the bare PyObject. Those additional fields represent the
"state" of the function object, and are required to describe it completely.

Instances of user-defined classes may contain arbitrary attributes; this
is implemented using a dictionary. We refer to this dictionary as the
'__dict__' attribute in Python code, but it is just another field in the
object struct, as anything else. In other words, arbitrary attributes are
also stored (indirectly) in the object struct.

So, at least when one looks at the CPython implementation, things are
rather simple: an object is a struct located at certain address
(determines its identity), has a certain type (a field in the struct) and
has a state (everything else in the struct).

You may want to say "value" instead of "state" in all the above
description, but I think it becomes confusing later.

Expressions: Evaluating an expression yields a result, and that result is
an *object*. One could say "the value of this expression" -- but remember
that it is an *object*, like everything else in Python. If one says
"objects have identity, type and value", one cannot say at the same time
"expression s return a value" because the word "value" has a different
meaning in both sentences.

Calling: Same problem applies to "call-by-value". If one says that objects
*have* a value (that implies that value is *part* of the object), it
itsn't its "value" what is passed when a function call is made. The
*whole* object is passed, not its "value" alone. Saying "call-by-object"
describes more accurately what actually happens.

Conclusion: To avoid any ambiguity, I'd say that "objects have identity,
type, and state" (not value), "expression s evaluate to an object" (again,
not value), and "Python passes arguments to functions using a
call-by-object protocol". Given these terms, even "the value of this
expression" might be acceptable because "value" could not be confused with
any "part" of an object.

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.

"state" is more common in OO theory, I think. I'd reserve "value" to any
informal description, and use "state" when refering to "anything the
object carries with itself".

I hope you see why I find the "value is object"
to be an unacceptable explanation of Python
objects.

Me too. I hope the above explanation helps to understand the difference.
It is based on a specific implementation, but I feel that describing what
CPython actually does is easier that talking about abstract concepts.
Perhaps somebody can come with an abstract explanation based on this
concrete examples.

[1] There is another field always present: ob_refcnt, but it should be
considered an implementation detail of the reference counting mechanism.
Additional fields may be present in a debug build of Python.

--
Gabriel Genellina

[Antoon Pardon]

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

On 2008-11-19, greg <greg@cosc.cant erbury.ac.nzwro te:

Antoon Pardon wrote:

>Call by value is officially defined in terms of assignment in
>a context where assignments means copying and in a definition
>of a specifix language.
>>
>You can't lift this part out of the definition of algol 60
>and say it applies equally well in languages with different
>assignment semantics.

>
But many other language designers, of both static and
dynamic languages, have done just that.
I'm not saying it *has* to be interpreted that way,
just that it *is* very often interpreted that way.
So you can't claim that it's not common usage.

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.

Now your falling back to how it is often interpreted.
It is very well possible that it is often interpreted
contrary to how it was intended. And since this
interpretation just as often results in misunderstandin gs
I don't think it is a usefull interpretation.

--
Antoon Pardon

[Terry Reedy]

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

Steven D'Aprano wrote:

On Tue, 18 Nov 2008 15:55:10 -0500, Terry Reedy wrote:

>To me, that distortion of his (and my) point is silly. 0 partipipates
>in numerous integer operations, whereas None participates in no NoneType
>operations. (Neither has attributes.) And that is the difference he is
>pointing at.

>
Why do you care about built-in NoneType operations?

Because class-specific operations are what make one class, and instances
thereof, different from another. If you don't care about that, fine,
but stop ridiculing those who do. Why do you oppose people
investigating specific differences?

Why don't we count the infinite number of useful operations
we can do to None that merely happen to not be built-in to the type?

Everything one can do with None is due to its status as a Python object.

We can convert None to a bool: bool(None)
We can append it to a list: alist.append(No ne)
We can convert it to a string: str(None), repr(None)
(In Python 2.6) We can ask how many bytes the None object uses.
We can ask the garbage collector how many objects refer to it:
gc.get_referrer s
We can count how many words have been written debating whether or not
None is a value.
>
and so forth. These operations aren't methods on NoneType but that is not
of any importance. The richness or poverty of methods in a class is
irrelevant.

To you, but not to me.

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

Terry Jan Reedy