Finding the instance reference of an object

[Astley Le Jasper]

Sorry for the numpty question ...

How do you find the reference name of an object?

So if i have this

bob = modulename.objectname()

how do i find that the name is 'bob'

[rurpy]

On Nov 18, 10:22 am, Steve Holden <[e-mail]
in thread "Python-URL! weekly Python news and links (Nov 17)":

ru***@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!!(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.

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]

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(None)
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_referrers
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]

En Wed, 19 Nov 2008 01:14:28 -0200, <ru***@yahoo.comescribió:

On Nov 18, 10:22 am, Steve Holden <[e-mail]
in thread "Python-URL! weekly Python news and links (Nov 17)":

>ru***@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
PyFunctionObject 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
"expressions 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), "expressions 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]

On 2008-11-19, greg <gr**@cosc.canterbury.ac.nzwrote:

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 misunderstandings
I don't think it is a usefull interpretation.

--
Antoon Pardon

[Terry Reedy]

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(None)
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_referrers
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

[Douglas Alan]

greg <gr**@cosc.canterbury.ac.nzwrites:

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]

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]

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]

ru***@yahoo.com wrote:

On Nov 18, 10:22 am, Steve Holden <[e-mail]
in thread "Python-URL! weekly Python news and links (Nov 17)":

>ru***@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!!(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.

>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 [phone] [phone]
Holden Web LLC http://www.holdenweb.com/

[Aaron Brady]

On Nov 19, 12:28*pm, Joe Strout <[e-mail]:

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]

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]

Joe Strout <jo*@strout.netwrites:

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

On Nov 19, 7:22*pm, greg <[e-mail]:

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]

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]

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]

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]

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]

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]

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

[Aaron Brady]

On Nov 21, 3:11*am, Duncan Booth <[e-mail]:

Steven D'Aprano <[e-mail]:

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]

Aaron Brady <ca********@gmail.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_list |
yield_expression)
target_list ::= target ("," target)* [","]
target ::= identifier
| "(" target_list ")"
| "[" target_list "]"
| attributeref
| subscription
| slicing
:^)

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

[Aaron Brady]

On Nov 21, 4:33*am, Duncan Booth <[e-mail]:

Aaron Brady <[e-mail]:

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:

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.

[greg]

Aaron Brady wrote:

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.

--
Greg

[greg]

Aaron Brady wrote:

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<intx = actual_parameter_expression;

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.

--
Greg

[greg]

Steven D'Aprano wrote:

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.

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

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.

--
Greg

[Aaron Brady]

On Nov 21, 7:06*pm, greg <[e-mail]:

Aaron Brady wrote:

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<intx = actual_parameter_expression;

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.

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.

[greg]

Aaron Brady wrote:

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.

--
Greg