Finding the instance reference of an object

[Terry Reedy]

Re: Finding the instance reference of an object [long and probablyboring]

Joe Strout wrote:

On Nov 6, 2008, at 10:35 PM, Steve Holden wrote:

Note: I tried to say "name" above instead of "variable" but I couldn't
bring myself to do it -- "name" seems to generic to do that job.

Python has two types of names. Some complex objects -- modules,
classes, and functions, and wrappers and subclasses thereof, have
'definition names' that are used instead of a 'value' to print a
representation. Otherwise, names are identifiers, the term used in the
grammar.

But I agree even two meaning is one too many. Maybe 'label' would be a
better short form for 'identifier'. 'Labeling' might be clearer for
many beginners than 'name-binding'.

Lots
of things have names that are not variables: modules have names, classes
have names, methods have names, and so do variables. If I say "name,"
an astute listener would reasonably say "name of what"

Common nouns, when instantiated, become the name of whatever particular
object they are associated with.

-- and I don't
want to have to say "name of some thing in a name space which can be
flexibly associated with an object" when the simple term "variable"
seems to work as well.

'Variable' has many more meanings than 'name' or 'label' and overall
seems to be more confusing, not less. I say this as an empirical
observation of c.l.p postings. You yourself switched back and forth
between two different meanings.

I'm with you there. To me, the consistent simplicity is exactly this:
all variables are object references, and these are always passed by value.

The me, this implies that the corresponding parameter should become a
reference to that reference value. In any case, the last 10 years of
this newsgroups shows that describing Python calling as 'by value'
confuses people so that they are surprised that mutating a list inside a
function results in the list being mutated outside the function.

But Python doesn't have those simple types, so there is a temptation to
try to skip this generalization and say that references are not values,

The Python Language Reference uses the word 'reference' but does not
define it. I take it to be 'whatever information an interpreter uses to
associate a name or collection slot with an object and to retrieve the
object (and possibly its value) when requested'.

Well of course. I'm pretty sure I've said repeatedly that Python
variables refer to objects on the heap.

Built-in objects are not allocated on the heap.

>(Please replace "heap" with "object space" if you prefer.)

They are in abstract object space, although CPython occasionally leaks
the abstraction in error messages about not being able to modify
non-heap objects.

I'm only saying that Python variables
don't contain any other type of value than references.

One problem with the word 'variable' is that variables are somethings
thought of as 'containing', as you did above. So you switch back and
forth between 'variables *are* references' and 'variables *contain*
references'. Whereas a name (noun) definitely *is* a reference and not
a container.

Ditto right back at you. :) So maybe here's the trouble: since all
Python variables are references,

Back to *is*.

But continuing to attempt to gloss over that fact, when you come to
parameter passing,

I believe most of us here try to follow Knuth's lead and use 'parameter'
for the local names and 'argument' for the value/object that gets
associated with the name.

not copied). You also have to describe the assignment operator as

In Python, assignment is not an operator by intentional design.

different from all other languages, since clearly that's not copying the
object either.

Python's assignment *statement* does what we routinely do in everyday
life when we assign new labels to things, whether permanently or
temporarily.

An assignment copies the RHS
reference into the LHS variable, nothing more or less.

Back to variable as container.
An assignment associates the RHS object(s) with the LHS target(s).

A parameter copies the argument reference into the formal parameter,

A function call associates objects derived from the argument expressions
and stored defaults with the function parameters.

Isn't that simple, clear, and far easier to explain?

Applied to my version, I agree ;-).

I wonder if that could be tested systematically. Perhaps we could round
up 20 newbies, divide them into two groups of 10, give each one a 1-page
explanation either based on passing object references by-value, or
passing values sort-of-kind-of-by-reference, and then check their
comprehension by predicting the output of some code snippets. That'd be
very interesting.

Except for your garbling of the alternative to your version, I agree.
I suspect that different people might do better with different
explanations, depending on background.

In my case, my understanding of Python became clear only once I stopped
listening to all the confusing descriptions here, and realized that
Python is no different from other OOP languages I already knew.

Whereas I learned Python without any OOP experience but enough knowledge
of C++ to know I did not want to go there.

Terry Jan Reedy

[Steve Holden]

Re: Finding the instance reference of an object

Steven D'Aprano wrote:

On Fri, 07 Nov 2008 11:37:28 -0500, Steve Holden wrote:
>

>Steven D'Aprano wrote:

>>On Fri, 07 Nov 2008 10:50:55 -0500, Steve Holden wrote:
>>>
>>>I am probably egregiously misunderstandin g. The practical difficulty
>>>with the "moving huge blocks of data" approach would appear to emerge
>>>when a function that gets passed an instance of some container then
>>>calls another function that references the same container as a global,
>>>for example.
>>I have no doubt whatsoever that such an implementation would be
>>fragile, complicated, convoluted and slow. In other words, it would be
>>terrible. But that's merely a Quality of Implementation issue. It would
>>still be Python.
>>>
>>>

>OK, more specifically: I don't see how changes to the copy of the
>(structure referenced by) the argument would be reflected in the global
>structure. In other words, it seems to involve a change of semantics to
>me, so I think I am misunderstandin g you.

>
What, you want me to come up with an implementation? Okay, fine.
>
The VM keeps a list of the namespaces that contain such "cloned" objects.
After each Python statement is executed, before the next one gets to run,
the VM runs through that list and synchronizes each object in the
caller's scope with the value of its clone in the function scope.
>
>
>

Right, so we replace references to values with references to namespaces?

Anyway, thanks. I'm really glad you stated up-front that this was not a
practical execution scheme.

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

[Terry Reedy]

Re: Finding the instance reference of an object [long and probablyboring]

Steven D'Aprano wrote:

On Fri, 07 Nov 2008 08:48:19 -0700, Joe Strout wrote:

Unfortunately, the term "name" is *slightly* ambiguous in Python. There
are names, and then there are objects which have a name attribute, which
holds a string. This attribute is usually called __name__ but sometimes
it's called other things, like func_name.

3.0 corrects that divergence.

>>def foo(): pass

>>foo.__name_ _

'foo'

You're assuming that call-by-sharing isn't a standard term. That's not
true. It's a standard term that is sadly not well known, I believe
because of the ignorance of most coders to the history of their own
discipline. (I include myself in that.)

-------------------------

http://en.wikipedia.org/wiki/Call_by_something#Call_by_sharing

Call by sharing

Also known as "call by object" or "call by object-sharing" is an
evaluation strategy first named by Barbara Liskov et al for the language
CLU in 1974[1]. It is used by languages such as Python[2] and Iota and
(as argued by some[3]) Java, although the term is not in common use by
the Java community. Call-by-sharing implies that values in the language
are based on objects rather than primitive types.

The semantics of call-by-sharing differ from call-by-reference in that
assignments to function arguments within the function aren't visible to
the caller (unlike by-reference sematics). However since the function
has access to the same object as the caller (no copy is made), mutations
to those objects within the function are visible to the caller, which
differs from call-by-value semantics.

Although this term has widespread usage in the Python community,
identical semantics in other languages such as Java and Visual Basic are
often described as call-by-value, where the value is implied to be a
reference to the object.

---------------------------------

http://www.pmg.csail.mit.edu/papers/thetaref/node34.html

Call by Sharing
The caller and called routine communicate only through the argument and
result objects; routines do not have access to any variables of the caller.

After the assignments of actual arguments to formal arguments, the
caller and the called routine share objects. If the called routine
modifies a shared object, the modification is visible to the caller on
return. The names used to denote the shared objects are distinct in the
caller and called routine; if a routine assigns an object to a formal
argument variable, there is no effect on the caller. From the point of
view of the invoked routine, the only difference between its formal
argument variables and its other local variables is that the formals are
initialized by its caller.

=============== ===========
Python object *do* have access to surrounding scopes, but the second
paragraph exact described Python, as does the corresponding Wikipedia entry.
=============== =============== ====
myweb.lmu.edu/dondi/fall2004/cmsi585/subroutines-in-depth.pdf

• Call by sharing
– Used by languages where variables are already references to objects
– Parameters are references to objects, but assignments to those parameters
don’t change them at the level of the caller — e.g. Java uses call-by-value
for primitives (int, char) and uses call-by-sharing for Objects
-------------------------------------------

And Google had other links to course notes using 'call by sharing'

Terry Jan Reedy

[Joe Strout]

Re: Finding the instance reference of an object [long and probablyboring]

On Nov 7, 2008, at 12:13 PM, Terry Reedy wrote:

Python has two types of names. Some complex objects -- modules,
classes, and functions, and wrappers and subclasses thereof, have
'definition names' that are used instead of a 'value' to print a
representation. Otherwise, names are identifiers, the term used in
the grammar.
>
But I agree even two meaning is one too many. Maybe 'label' would
be a better short form for 'identifier'. 'Labeling' might be
clearer for many beginners than 'name-binding'.

I actually rather like "identifier ," though it seems a little too
technical for casual use. On the other hand, "label" seems too
arbitrary -- "variable" is a common term, and accurate enough to me.

'Variable' has many more meanings than 'name' or 'label' and overall
seems to be more confusing, not less. I say this as an empirical
observation of c.l.p postings. You yourself switched back and forth
between two different meanings.

Did I? What were they? I thought I had a clear idea what I mean by
it (and, as far as I know, it's consistent with what everybody else
means by it too). The only oddity in Python is that things you might
not expect to be variables (such as module names) actually are. But
that's a succinct way to express that observation; saying "module
names are variables too" seems to imply all the right things (e.g.
that you can assign new values to them, or assign them to other
variables).

>I'm with you there. To me, the consistent simplicity is exactly
>this: all variables are object references, and these are always
>passed by value.

>
To me, this implies that the corresponding parameter should become a
reference to that reference value.

Really? You've just described passing an object reference by
reference. If "passing a reference by value" implies adding an
additional reference to it, then what would "passing a reference by
reference" mean to you? And, examining your thought process, can you
explain where that implication came from?

In any case, the last 10 years of this newsgroups shows that
describing Python calling as 'by value' confuses people so that they
are surprised that mutating a list inside a function results in the
list being mutated outside the function.

Yes, but that would happen ONLY when they also think that a variable
actually contains the object data. And since there are many here
trying to claim exactly that, I think that is the root cause of the
problem, not calling parameter passing "by value."

And this belief (that the value of a variable is an object) leads to
other mistaken beliefs too, such as that assignment should make a copy:

x = y
x.foo = bar

Anyone surprised by the list mutation inside a function should also be
surprised to find that y.foo = bar. I think we should simply address
the root cause of that confusion, not try to redefine their
understanding of how parameters are passed, and ALSO redefine what
assignment means.

>But Python doesn't have those simple types, so there is a
>temptation to try to skip this generalization and say that
>references are not values,

>
The Python Language Reference uses the word 'reference' but does not
define it. I take it to be 'whatever information an interpreter
uses to associate a name or collection slot with an object and to
retrieve the object (and possibly its value) when requested'.

Sure, that's fine. It doesn't really matter how it's implemented.
What matters is that a name or collection slot somehow refers to an
object, and whatever the form of that reference is, it is copied (*)
to the LHS of an assignment or to the formal parameter of a function
call.

(*) I was going to say "transferre d" but when something is transferred
from A to B, it implies that B gains it and A loses it. "Copied" has
the right implication: that afterwards, both A and B now have it.

I'm only saying that Python variables
>don't contain any other type of value than references.

>
One problem with the word 'variable' is that variables are
somethings thought of as 'containing', as you did above. So you
switch back and forth between 'variables *are* references' and
'variables *contain* references'.

Perhaps this is the two meanings you mentioned above. I'm not sure I
see any useful dichotomy here, though. In C, we say that this
variable is an integer, that variable is a character, the one over
there is a double. This is unambiguous shorthand for "the declared
type of this variable is such-and-so", and each such variable contains
data of that type. So there's no harm in saying that a variable is an
integer, or that a variable contains an integer, as the context
requires.

In Python, AFAICT, there is only one type, the object reference. So,
the type of every variable is 'reference', and each one contains a
reference.

Whereas a name (noun) definitely *is* a reference and not a
container.

Yes, I'll grant you that about it. "Label" and "identifier " has that
connotation as well. But as long as we recognize that what a Python
variable contains is a reference, I don't see that it matters. And
this is a very useful recognition, since it implies the correct things
about assignment and parameter-passing.

I believe most of us here try to follow Knuth's lead and use
'parameter' for the local names and 'argument' for the value/object
that gets associated with the name.

Fine with me. (I've also seen "formal parameter" and "actual
parameter" respectively, but hey, I'm flexible.)

Python's assignment *statement* does what we routinely do in
everyday life when we assign new labels to things, whether
permanently or temporarily.

Super, that's great, but not very helpful, at least to someone who
knows any other programming language. For them, it's better to point
out that it does what those other languages routinely do when they
assign an expression to an identifier.

>I wonder if that could be tested systematically. Perhaps we could
>round up 20 newbies, divide them into two groups of 10, give each
>one a 1-page explanation either based on passing object references
>by-value, or passing values sort-of-kind-of-by-reference, and then
>check their comprehension by predicting the output of some code
>snippets. That'd be very interesting.

>
Except for your garbling of the alternative to your version, I agree.
I suspect that different people might do better with different
explanations, depending on background.

Could be.

Maybe we could run such an experiment at PyCon, pulling in non-
attendees from the hallway and getting them to take the test in
exchange for a free donut or coffee.

Best,
- Joe

[Joe Strout]

Re: Finding the instance reference of an object [long and probablyboring]

On Nov 7, 2008, at 12:35 PM, Terry Reedy wrote:

http://en.wikipedia.org/wiki/Call_by_something#Call_by_sharing

>
Call by sharing
>
Also known as "call by object" or "call by object-sharing" is an
evaluation strategy first named by Barbara Liskov et al for the
language CLU in 1974[1]. It is used by languages such as Python[2]
and Iota and (as argued by some[3]) Java, although the term is not
in common use by the Java community. Call-by-sharing implies that
values in the language are based on objects rather than primitive
types.
>
The semantics of call-by-sharing differ from call-by-reference in
that assignments to function arguments within the function aren't
visible to the caller (unlike by-reference sematics). However since
the function has access to the same object as the caller (no copy is
made), mutations to those objects within the function are visible to
the caller, which differs from call-by-value semantics.
>
Although this term has widespread usage in the Python community,
identical semantics in other languages such as Java and Visual Basic
are often described as call-by-value, where the value is implied to
be a reference to the object.

You know, people rip on Wikipedia, but I'm often surprised at how
frequently it succinctly and accurately describes a topic, even when
it is a topic of much controversy. The above summary seems spot on.
My difficulty, I guess, is that I'm coming from the Java/VB/RB
community, where the semantics are exactly the same as Python, and
where it makes perfect sense to call it call-by-value (since it is a
trivial generalization of the very same evaluation strategy used on
other types). But I get here, and there is widespread use of this
call-by-sharing term (though my initial impressions were much more
disparate and confusing than the above concise summary makes it sound).

Thanks for pointing this out. I'd only found the entry on evaluation
strategies, which makes no mention of call-by-sharing.

http://www.pmg.csail.mit.edu/papers/thetaref/node34.html

>
Call by Sharing
The caller and called routine communicate only through the argument
and result objects; routines do not have access to any variables of
the caller.
>
After the assignments of actual arguments to formal arguments, the
caller and the called routine share objects. If the called routine
modifies a shared object, the modification is visible to the caller
on return. The names used to denote the shared objects are distinct
in the caller and called routine; if a routine assigns an object to
a formal argument variable, there is no effect on the caller. From
the point of view of the invoked routine, the only difference
between its formal argument variables and its other local variables
is that the formals are initialized by its caller.
>
=============== ===========
Python object *do* have access to surrounding scopes, but the second
paragraph exact described Python, as does the corresponding
Wikipedia entry.

Well yes, but it exactly describes VB.NET, RB, Java, and C++ as well
(when talking about object types rather than primitive types).

=============== =============== ====
myweb.lmu.edu/dondi/fall2004/cmsi585/subroutines-in-depth.pdf
>
• Call by sharing
– Used by languages where variables are already references to objects
– Parameters are references to objects, but assignments to those
parameters
don’t change them at the level of the caller — e.g. Java uses call-
by-value
for primitives (int, char) and uses call-by-sharing for Objects

Well, not according to the Java specification, it doesn't. But these
sources finally make it clear that "call-by-sharing" is just a special
case of call-by-value when the value is an object reference. So, it's
accurate to say that Java (and all the other languages under
discussion) always use call-by-value, but some of those calls
(depending on the parameter data type) may also be described as call-
by-sharing.

I suppose it's reasonable that if you use a language where some types
are references and some types are not, the simplest thing is to
describe all calls as call-by-value (except for those with an optional
by-reference syntax, like C++ and RB/.NET). But if you come from a
language where all types are references, then it's reasonable to
describe all calls as call-by-sharing (provided the language doesn't
also support call-by-reference).

So. How about this for a summary?

"Python uses call-by-sharing. That's a special case of call-by-value
where the variables are references to objects; it is these references
that are copied to the parameters, not the objects themselves. For
users of other languages, this is the same semantics used for objects
in Java, RB/VB.NET, and C++ when dealing with objects."

Best,
- Joe

[Arnaud Delobelle]

Re: Finding the instance reference of an object [long and probably boring]

Joe Strout <joe@strout.net writes:

So. How about this for a summary?
>
"Python uses call-by-sharing. That's a special case of call-by-value
where the variables are references to objects; it is these references
that are copied to the parameters, not the objects themselves. For
users of other languages, this is the same semantics used for objects
in Java, RB/VB.NET, and C++ when dealing with objects."

Here's a story about call by sharing:

One day a black cat came strolling into our garden. It seemed quite
hungry so we gave it some milk and food remains. The cat drank the milk
and ate the food, stayed for a bit then walked away. A couple of days
later it came back, miaowing, so we fed it again. It started coming to
see us almost every day, sometimes sleeping in the house, sometimes
disappearing for a day or two. We started thinking of it as our cat and
we *named* it Napoleon. Napoleon became very popular and stayed at home
more and more often, and very young son was very fond of it, calling it
something like 'Polion'.

Unfortunately Napoleon got infested with fleas and we had to take him to
the vet. The vet scanned Napoleon with a little machine and discovered
that it had an ID chip. This revealed that Napoleon was really called
Nelson (ironically!) and belonged to a house down our road. We
contacted them and they were happy to 'share' the cat with us. By this
time the cat answered to the name of Napoleon so we carried on calling
it this name.

This story ends quite sadly. One day Napoleon escaped out the front
door and got run over by a passing van. Our son kept asking for Polion
so we decided to get a new cat and called him Napoleon as well (we
decided it would be easier for him!).

Now some questions about the story:

1. Is Napoleon a copy of Dobby or are they the same cat?

2. Is Polion a copy of Napoleon or are they the same cat?

3. When we got rid of Napoleon's fleas, was Nelson deflea-ed as well?

4. When Napoleon died, did Nelson die as well?

5. When we got a new Napoleon, does this mean that our neighbours got a
new Nelson?

Now a question about the questions about the story:

To be able to understand the story and answer questions 1-5, do we
need to think of Napoleon, Nelson and Polion as variables containing
references to cat objects, or is it enough to think of them as three
names for cats?

--
Arnaud

[Steve Holden]

Re: Finding the instance reference of an object [long and probablyboring]

Joe Strout wrote:

On Nov 7, 2008, at 12:13 PM, Terry Reedy wrote:

[...]

>>I wonder if that could be tested systematically. Perhaps we could
>>round up 20 newbies, divide them into two groups of 10, give each one
>>a 1-page explanation either based on passing object references
>>by-value, or passing values sort-of-kind-of-by-reference, and then
>>check their comprehension by predicting the output of some code
>>snippets. That'd be very interesting.

>>
>Except for your garbling of the alternative to your version, I agree.
>I suspect that different people might do better with different
>explanations , depending on background.

>
Could be.
>
Maybe we could run such an experiment at PyCon, pulling in non-attendees
from the hallway and getting them to take the test in exchange for a
free donut or coffee.
>

+1: great idea! It would make a good video too ...

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 [long and probablyboring]

On Nov 7, 3:03 pm, Arnaud Delobelle <arno...@google mail.comwrote:

Joe Strout <j...@strout.ne twrites:

So.  How about this for a summary?

>

"Python uses call-by-sharing.  That's a special case of call-by-value
where the variables are references to objects; it is these references
that are copied to the parameters, not the objects themselves.  For
users of other languages, this is the same semantics used for objects
in Java, RB/VB.NET, and C++ when dealing with objects."

>
Here's a story about call by sharing:
>
One day a black cat came strolling into our garden.  It seemed quite
hungry so we gave it some milk and food remains.  The cat drank the milk
and ate the food, stayed for a bit then walked away.  A couple of days
later it came back, miaowing, so we fed it again.  It started coming to
see us almost every day, sometimes sleeping in the house, sometimes
disappearing for a day or two.  We started thinking of it as our cat and
we *named* it Napoleon.  Napoleon became very popular and stayed at home
more and more often, and very young son was very fond of it, calling it
something like 'Polion'.
>
Unfortunately Napoleon got infested with fleas and we had to take him to
the vet.  The vet scanned Napoleon with a little machine and discovered
that it had an ID chip.  This revealed that Napoleon was really called
Nelson (ironically!) and belonged to a house down our road.  We
contacted them and they were happy to 'share' the cat with us.  By this
time the cat answered to the name of Napoleon so we carried on calling
it this name.
>
This story ends quite sadly.  One day Napoleon escaped out the front
door and got run over by a passing van.  Our son kept asking for Polion
so we decided to get a new cat and called him Napoleon as well (we
decided it would be easier for him!).
>
Now some questions about the story:

Sorry didn't read above yet.

1. Is Napoleon a copy of Dobby or are they the same cat?

Same cat.

2. Is Polion a copy of Napoleon or are they the same cat?

Same cat.

3. When we got rid of Napoleon's fleas, was Nelson deflea-ed as well?

Yes.

4. When Napoleon died, did Nelson die as well?

No, honey. He lives on in all of us.

5. When we got a new Napoleon, does this mean that our neighbours got a
   new Nelson?

No, darling, Nelson is just sleeping. When we got a New Orleans,
where did the old one go?

Now a question about the questions about the story:
>
   To be able to understand the story and answer questions 1-5, do we
   need to think of Napoleon, Nelson and Polion as variables containing
   references to cat objects, or is it enough to think of them as three
   names for cats?

I think they are names, implying that Python has a different "variable
model" than C++.

However, a[0] isn't exactly a name, per se, and if you say that 'b'
and 'a[0]' are names of an object, then 'a[1-1]', 'a[2*0]', etc. are
all names of it. Furthermore, some class models variables like this:

a.b= 'abc'
a.c= 'def'
a.d= 'ghi'

It also allows index access: a[0], a[1], a[2], respectively. 'abc'
has two names: 'a.b', and 'a[0]'. Correct?

[Arnaud Delobelle]

Re: Finding the instance reference of an object [long and probably boring]

Aaron Brady <castironpi@gma il.comwrites:

Furthermore, some class models variables like this:
>
a.b= 'abc'
a.c= 'def'
a.d= 'ghi'
>
It also allows index access: a[0], a[1], a[2], respectively. 'abc'
has two names: 'a.b', and 'a[0]'. Correct?

You know very well that a.b and a[0] aren't names, they are function
calls written in short hand ;)

a.b is getattr(a, 'b')
a[0] is getattr(a, '__getitem__')( 0)

So they just return an object, which happens to be the same :)

--
Arnaud

[Douglas Alan]

Re: Finding the instance reference of an object

Joe Strout <joe@strout.net writes:

As for where I get my definitions from, I draw from several sources:
>
1. Dead-tree textbooks

You've been reading the wrong textbooks. Read Liskov -- she's called
CLU (and hence Python's) calling strategy "call-by-sharing" since the
70s.

2. Wikipedia [2] (and yes, I know that has to be taken with a grain of
salt, but it's so darned convenient)
3. My wife, who is a computer science professor and does compiler
research
4. http://javadude.com/articles/passbyvalue.htm (a brief but excellent
article)
5. Observations of the "ByVal" (default) mode in RB and VB.NET
6. My own experience implementing the RB compiler (not that
implementation details matter, but it forced me to think very
carefully about references and parameter passing for a very long time)
>
Not that I'm trying to argue from authority; I'm trying to argue from
logic. I suspect, though, that your last comment gets to the crux of
the matter, and reinforces my guess above: you don't think c-b-v means
what most people think it means. Indeed, you don't think any of the
languages shown at [1] are, in fact, c-b-v languages. If so, then we
should focus on that and see if we can find a definitive answer.

I'll give you the definitive answer from a position of authority,
then. I took Barbara Liskov's graduate-level class in programming
language theory at MIT, and she called what Python does
"call-by-sharing".

|>oug

[Douglas Alan]

Re: Finding the instance reference of an object

Joe Strout <joe@strout.net writes:

Yes, OK, that's great. But there are several standard pass-by-
somethings that are defined by the CS community, and which are simple
and clear and apply to a wide variety of languages. "Pass by object"
isn't one of them.

"Call-by-sharing" *is* one of them, and the term has been around since
the 70s:

http://hopl.murdoch.edu.au/showlanguage.prx?exp=637

I guess if you want to campaign for it as a shorthand for "object
reference passed by value," you could do that, and it's not
outrageous.

There's no need for a campaign. The term has already been used in the
academic literature for 34 years.

But to anybody new to the term, you should explain it as exactly
that, rather than try to claim that Python is somehow different from
other OOP languages where everybody calls it simply pass by value.

It's not true that "everybody calls it simply pass by value".

OK, if there were such a thing as "pass-by-object" in the standard
lexicon of evaluation strategies, I would be perfectly happy saying
that a system has it if it behaves as though it has it, regardless of
the underpinnings.

There is "call-by-sharing" in the standard lexicon of evaluation
strategies, and it's been in the lexicon since 1974.

However, if you really think the term is that handy, and we want to
agree to say "Python uses pass by object" and answer the inevitable
"huh?" question with "that's shorthand for object references passed by
value," then I'd be OK with that.

Excellent. We can all agree to get along then!

|>oug

[Aaron Brady]

Re: Finding the instance reference of an object [long and probablyboring]

On Nov 7, 3:39 pm, Arnaud Delobelle <arno...@google mail.comwrote:

Aaron Brady <castiro...@gma il.comwrites:

 Furthermore, some class models variables like this:

>

a.b= 'abc'
a.c= 'def'
a.d= 'ghi'

>

It also allows index access: a[0], a[1], a[2], respectively.  'abc'
has two names: 'a.b', and 'a[0]'.  Correct?

>
You know very well that a.b and a[0] aren't names, they are function
calls written in short hand ;)
>
a.b   is   getattr(a, 'b')
a[0]  is   getattr(a, '__getitem__')( 0)
>
So they just return an object, which happens to be the same :)
>
--
Arnaud

Therefore objects don't need names to exist. Having a name is
sufficient but not necessary to exist. Being in a container is
neither necessary -nor- sufficient.

a is the name of an object. The object is associated with a
dictionary you can usually access. 'b' is a key in the dictionary.

[greg]

Re: Finding the instance reference of an object

Steven D'Aprano wrote:

Python's behaviour is not the same as what
Pascal, or C, calls call-by-value.

Python's assignment is not the same as what Pascal or C calls
assignment, either. Yet we don't hear anyone claim that the
term "assignment " shouldn't be used in Python.

The difference between call-by-value in Python and Pascal is
exactly the same difference as there is between assignment
in Python and Pascal. Why should we throw out one term but
not the other?

--
Greg

[Steven D'Aprano]

Re: Finding the instance reference of an object [long and probablyboring]

On Fri, 07 Nov 2008 13:05:16 -0700, Joe Strout wrote:

In Python, AFAICT, there is only one type, the object reference. So,
the type of every variable is 'reference', and each one contains a
reference.

This is wrong. If we take "variable" to mean "name", then Python names do
not have types. But *objects* have types, and there are many of them:

>>a = 23; type(a)

<type 'int'>

>>a = "foo"; type(a)

<type 'str'>

>>a = []; type(a)

<type 'list'>

But a name that isn't bound to an object doesn't have a type:

>>del a; type(a)

Traceback (most recent call last):
File "<stdin>", line 1, in <module>
NameError: name 'a' is not defined

The type information is associated with the object, not with the name.

It is possible that, in the C implementation, there is a C-type
'reference' and all(?) C variables relating to the implementation of
namespaces have that type. Possibly. But even if true, that's the wrong
level of description.


--
Steven

[Steven D'Aprano]

Re: Finding the instance reference of an object

On Sat, 08 Nov 2008 17:12:00 +1300, greg wrote:

Steven D'Aprano wrote:

>Python's behaviour is not the same as what Pascal, or C, calls
>call-by-value.

>
Python's assignment is not the same as what Pascal or C calls
assignment, either. Yet we don't hear anyone claim that the term
"assignment " shouldn't be used in Python.

Er, you're not from around here are you?

I admit that sometimes I slip into bad habits, but generally the accepted
terminology is that x = 1 binds the object 1 to the name x.

The difference between call-by-value in Python and Pascal is exactly the
same difference as there is between assignment in Python and Pascal. Why
should we throw out one term but not the other?

Exactly.



--
Steven