Finding the instance reference of an object

[Bruno Desthuilliers]

Re: Finding the instance reference of an object

greg a écrit :

Aaron Brady wrote:
>

>Maybe I missed this part. What does the phrase, "value of variable x"
>mean in Python?

>
I didn't use the phrase "value of variable x" anywhere in my
definitions, so it doesn't matter what it means, or even
whether it means anything at all.
>

>If "value of 'x'" is not defined, we should agree on a definition
>that's really clear and useful, favoring useful. After that's
>established, we can proceed to evaluating what 'call by value' would
>behave like, which would then determine if Python behaves like it.

>
There you go, getting distracted by that annoying word
"value". Forget about it, we don't need it!
>

Err... So what does "call by value" means if "values" doesn't mean
anything ?-)

[Steven D'Aprano]

Re: Finding the instance reference of an object

On Fri, 31 Oct 2008 20:22:23 +1300, greg wrote:

Steven D'Aprano wrote:
>

>Which definition of call-by-value? Certainly not the one that most
>people are familiar with, where c-b-v implies that calling a function
>with a large array will copy the entire array.

>
But that's only true in languages where *assigning* a large array will
also copy the entire array.

Maybe, maybe not. To be consistent, it should be true. But how do you
know if a language you are unfamiliar with is consistent?

In any case, to somebody only familiar with the classical value-vs-
reference model, Python seems rather inconsistent:


x = 1
y = x # does assignment make copies?
y += 1
assert x == 1
=succeeds, which implies that Python makes a copy when assigning

x = [1]
y = x # does assignment make copies?
y += [1]
assert x == [1]
=fails, which implies that Python uses references when assigning

Hence you get people who argue that Python does call-by-value for numbers
and call-by-reference for lists -- and yes, I've seen people make that
exact argument.

The reality is that Python isn't inconsistent, it merely seems to be if
you assume it is some other language. Python actually treats numbers and
lists identically.

When people discover that Python's behaviour doesn't fall neatly into
their preconceived notions of c-b-v and c-b-r, there are two ways of
dealing with that:

(1) Accept that perhaps there's at least one more way of doing assignment
and parameter passing.

(2) Or jump through hoops trying to force how Python works to somehow
match your preconceptions.

This does not happen in Python, therefore
there is no reason to suppose that it will happen when passed as a
parameter.

Of course there is a reason: we've been told that Python is call by
value, and call by value implies that a copy is made when you pass it to
a function. The fact that many programmers already have an idea of what
they think c-b-v implies is what makes calling Python c-b-v such a
pernicious mistake. If you want to call Python "call by ginger" I won't
object, because most people have no preconceived ideas of what call by
ginger means and therefore won't be lured into incorrect assumptions
about Python.

Before you can understand parameter passing, whether by-value or
by-reference, you first have to understand how assignment works *in the
language concerned*, not some other language you happen to know
previously.

It's certainly true that the baggage people bring from their previous
languages can sometimes be a serious barrier, but that especially happens
when folk insist on using the same terminology to describe different
things.

For example, to somebody coming to Python from Lisp or Scheme, the word
"list" carries particular connotations. It's unfortunate that Python
lists are not like Lisp lists, but we're stuck with that now, and besides
there's only so many good names for a list-like array, and whatever name
was chosen would trip up somebody. Another example, augmented assignment
in Python trips up C programmers, because x += y looks the same but
behaves differently than x += y in C.

There's enough difficulty with learning a new programming language
without people adding to it by misusing terms like "call by value" to
describe what Python does.


--
Steven

[Steven D'Aprano]

Re: Finding the instance reference of an object

On Thu, 30 Oct 2008 19:55:57 -0700, Aaron Brady wrote:

On Oct 30, 9:05 pm, Steven D'Aprano <st...@REMOVE-THIS-
cybersource.com .auwrote:

>On Fri, 31 Oct 2008 13:58:13 +1300, greg wrote:

Dale Roberts wrote:

>>

snip

>>

If they understand how assignment works in Python, that tells them
all they need to know.

>>
>Nonsense.

>
Maybe I missed this part. What does the phrase, "value of variable x"
mean in Python? Is it the same as what it means in C, Pascal, etc.?
>
In other words,
>

>>>x= [ 2, 3, 4 ]
>>>'0x%x'%id( x )

'0xb39dd0'
>
What is the value of 'x'?
a) [ 2, 3, 4 ]
b) An object with contents [ 2, 3, 4 ]
c) 0xb39dd0
d) None of the above.

Solution a) is just shorthand for b), because there are (or at least
could be) many such objects [2, 3, 4]. So I'd accept either a) or b) as
reasonable answers.

Solution c) is the answer that is required for "Python is call-by-value"
to be correct.

If "value of 'x'" is not defined, we should agree on a definition that's
really clear and useful, favoring useful.

The ordinary dictionary meaning is sufficient: "what is denoted by a
symbol".

After that's established, we
can proceed to evaluating what 'call by value' would behave like, which
would then determine if Python behaves like it.

Call by value is traditionally defined in at least some languages as
meaning that a copy of the value of the parameter is passed to the
function. Those languages include C and Pascal, and possibly Basic. I'd
estimate that 80% of programmers over the last 40 years have had their
understanding of "call by whatever" shaped by those three languages.

So, logically, if... she... weighs... the same as a duck,... she's made
of wood.

Nice one :)


--
Steven

[Arnaud Delobelle]

Re: Finding the instance reference of an object

On Oct 31, 9:12 am, Steven D'Aprano <st...@REMOVE-THIS-
cybersource.com .auwrote:
[...]

There's enough difficulty with learning a new programming language
without people adding to it by misusing terms like "call by value" to
describe what Python does.

Maybe it could be named 'call by assignment'?

Then the focus might shift towards misconceptions about assignment and
augmented assignment, which are more often than not at the root of
people's misunderstandin gs.

--
Arnaud

[Grant Edwards]

Re: Finding the instance reference of an object

On 2008-10-31, greg <greg@cosc.cant erbury.ac.nzwro te:

Dale Roberts wrote:
>

>Just as the Pass By Reference idiom deserves a unique name to
>distinguish it from Pass By Value (even though it is often Pass By
>(address) Value internally), so Pass By Object Reference deserves a
>unique name (even though it too is Pass By (reference) Value
>internally).

>
Since Python only has one parameter passing mechanism,
there's no need to give it a name at all. If you're
having to explain it, just explain it, and don't
bother naming it!

Unfortunately, that's not really how the human mind works. It
likes to have names for things and put them in categories of
like things. Hence the large collection of nouns in all human
languages.

--
Grant Edwards grante Yow! Th' MIND is the Pizza
at Palace of th' SOUL
visi.com

[Dale Roberts]

Re: Finding the instance reference of an object

On Oct 31, 3:15 am, greg <g...@cosc.cant erbury.ac.nzwro te:

Dale Roberts wrote:

Just as the Pass By Reference idiom deserves a unique name to
distinguish it from Pass By Value (even though it is often Pass By
(address) Value internally), so Pass By Object Reference deserves a
unique name (even though it too is Pass By (reference) Value
internally).

>
Since Python only has one parameter passing mechanism,
there's no need to give it a name at all. If you're
having to explain it, just explain it, and don't
bother naming it!
>
--
Greg

On Oct 31, 3:15 am, greg <g...@cosc.cant erbury.ac.nzwro te:

Dale Roberts wrote:

Just as the Pass By Reference idiom deserves a unique name to
distinguish it from Pass By Value (even though it is often Pass By
(address) Value internally), so Pass By Object Reference deserves a
unique name (even though it too is Pass By (reference) Value
internally).

>
Since Python only has one parameter passing mechanism,
there's no need to give it a name at all. If you're
having to explain it, just explain it, and don't
bother naming it!
>
--
Greg

But then why bother having any other names at all for other languages
that have only one calling mechanism, like Call By Name, Call By Macro
Expansion, etc.

If it is a different process, it needs a different name. OR, as you
suggest, no name at all, just an explanation.

But please don't give it the WRONG name!

[Dale Roberts]

Re: Finding the instance reference of an object

On Oct 31, 2:27 am, greg <g...@cosc.cant erbury.ac.nzwro te:

Dale Roberts wrote:

Are you
saying that C++ is capable of using the Call By Reference idiom, but C
is not, because C does not have a reference designation for formal
function parameters?

>
Call by reference is not an "idiom", it's a *language
feature*.
...
You can use an idiom in C to get the same effect, but this
is not the same thing as the language having it as a feature.

Okay, I'll grant that, but is there a language other than Python that
uses the Call By Value feature that does not do it by assigning/
copying the result of an expression into the formal parameter?

The terms "result" and "value" are generally understood to refer to
the working data of the program, not the internal workings of the
interpreter, VM, or compiler.

So, yes, internally the C Python runtime does use Call By Value. It's
written in C after all - that's all it can do.

But Call By Value is not a feature of the Python language.

dale

[Somebody unplug my network cable! I can't stop!]

[pjacobi.de@googlemail.com]

Re: Finding the instance reference of an object

Instead of comparing integers:

x = 1
y = x # does assignment make copies?
y += 1
assert x == 1
=succeeds, which implies that Python makes a copy when assigning

with lists:

x = [1]
y = x # does assignment make copies?
y += [1]
assert x == [1]
=fails, which implies that Python uses references when assigning

Compare lists with tupels:

x = (1,)
y = x # does assignment make copies?
y += (1,)
assert x == (1,)
=succeeds, which implies *what*?

Regards,
Peter

[Duncan Booth]

Re: Finding the instance reference of an object

pjacobi.de@goog lemail.com wrote:

>x = 1
>y = x # does assignment make copies?
>y += 1
>assert x == 1
>=succeeds, which implies that Python makes a copy when assigning

>
with lists:
>

>x = [1]
>y = x # does assignment make copies?
>y += [1]
>assert x == [1]
>=fails, which implies that Python uses references when assigning

>
Compare lists with tupels:
>
x = (1,)
y = x # does assignment make copies?
y += (1,)
assert x == (1,)
>=succeeds, which implies *what*?

All any of this does is 'implies that += may create a new object or may
mutate an existing object. RTFM: Python Reference Manual 6.3.1

"An augmented assignment expression like x += 1 can be rewritten as x = x +
1 to achieve a similar, but not exactly equal effect. In the augmented
version, x is only evaluated once. Also, when possible, the actual
operation is performed in-place, meaning that rather than creating a new
object and assigning that to the target, the old object is modified
instead."

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

[Douglas Alan]

Re: Finding the instance reference of an object

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

Douglas Alan wrote:

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

>

>>This holds for *all* languages that I know about, both static and
>>dynamic.

>

>Then you don't know about all that many languages. There are
>languages that use call-by-name, and those that use
>call-by-value-return. Some use call-by-need and others do
>call-by-macro-expansion. Etc.

>
I didn't mean that these are the only two parameter passing
mechanisms in existence -- I know there are others.

I don't follow you. You stated that once you understand how
assignment works, you understand the calling mechanism. That's just
not true. Algol, for instance, did assignment-by-value but
call-by-name.

>If I tell you, for instance, that Java, Python, Ruby, JavaScript,
>Lisp, and CLU all use call-by-sharing, then I have said something that
>makes a similarity among these languages easier to state and easier to
>grasp.

>
If you told me they use "assignment by sharing", that would tell me
a lot *more* about the language than just talking about parameter
passing.

Not really. Call-by-sharing virtually implies that the language does
assignment-by-sharing. (I know of no counter-examples, and it is
difficult to see how a violation of this rule-of-thumb would be useful
in any new language.) Stating that a language does
assignment-by-sharing does not imply that it does call-by-sharing. Or
at least not exclusively so. Cf. certain dialects of Lisp. Also C#,
which supports a variety of argument passing strategies.

|>oug

[Steven D'Aprano]

Re: Finding the instance reference of an object

On Fri, 31 Oct 2008 08:42:53 -0700, pjacobi.de wrote:

Instead of comparing integers:
>

>x = 1
>y = x # does assignment make copies? y += 1
>assert x == 1
>=succeeds, which implies that Python makes a copy when assigning

>
with lists:
>

>x = [1]
>y = x # does assignment make copies? y += [1]
>assert x == [1]
>=fails, which implies that Python uses references when assigning

>
Compare lists with tupels:
>
x = (1,)
y = x # does assignment make copies? y += (1,)
assert x == (1,)
=succeeds, which implies *what*?

To somebody who is stuck in the traditional mentality of "call by
reference" versus "call by value", it implies that Python copies tuples
and ints (and strings, and frozensets) but not lists (and dicts and sets
and class instances).

They would be wrong, but when you start with faulty assumptions that is
often the case. The assumption that there are only two calling
conventions is such a pernicious assumption. Look at how many thousands
of words have been spent trying to get Joe to understand that c-by-r and
c-b-v are not the only two options, and that what Python does is not
either c-b-r or c-b-v.


--
Steven

[Steven D'Aprano]

Re: Finding the instance reference of an object

On Fri, 31 Oct 2008 16:02:53 +0000, Duncan Booth wrote:

pjacobi.de@goog lemail.com wrote:
>

>>x = 1
>>y = x # does assignment make copies? y += 1
>>assert x == 1
>>=succeeds, which implies that Python makes a copy when assigning

>>
>with lists:
>>

>>x = [1]
>>y = x # does assignment make copies? y += [1]
>>assert x == [1]
>>=fails, which implies that Python uses references when assigning

>>
>Compare lists with tupels:
>>
>x = (1,)
>y = x # does assignment make copies? y += (1,)
>assert x == (1,)
>>=succeeds, which implies *what*?

>
All any of this does is 'implies that += may create a new object or may
mutate an existing object. RTFM: Python Reference Manual 6.3.1

The exact test isn't important. If you don't like those tests, replace
them with something else: y = y + [1] perhaps, or y.sort(), or whatever
you like. Naturally you will get different results according to whatever
specific test you try, and the interpretation of those results will
therefore be different. But no matter what tests are done, somebody who
fails to understand Python's calling model (or if you prefer, its
assignment model) will wrongly interpret the results they see in terms of
a model they do understand.

Because call by reference and call by value are such older and
established models, and used in such historically popular languages like
C and Pascal, they are the most likely incorrect assumptions people will
start from.


--
Steven

[greg]

Re: Finding the instance reference of an object

Steven D'Aprano wrote:

Consequently people who know these other
languages come along and ask "So is Python call by value or call by
reference?".

And if you don't know *exactly* what *they* understand by those
terms, you can't answer that directly without running the
risk of confusing them in some way. So instead, you just
tell them how it works, and leave them to decide for themselves
what name they want to give it.

--
Greg

[Aaron Brady]

Re: Finding the instance reference of an object

On Oct 31, 4:23 am, Steven D'Aprano <st...@REMOVE-THIS-
cybersource.com .auwrote:

On Thu, 30 Oct 2008 19:55:57 -0700, Aaron Brady wrote:

snip

After that's established, we
can proceed to evaluating what 'call by value' would behave like, which
would then determine if Python behaves like it.

>
Call by value is traditionally defined in at least some languages as
meaning that a copy of the value of the parameter is passed to the
function. Those languages include C and Pascal, and possibly Basic. I'd
estimate that 80% of programmers over the last 40 years have had their
understanding of "call by whatever" shaped by those three languages.

I see. Python promises not to make a copy unless you explicitly tell
it to. Therefore, Python is not call-by-value. Did I miss a step?

Formally:

M: Call-by-value makes a copy.
m: Python does not make a copy.
C: Python is not call-by-value.

So, logically, if... she... weighs... the same as a duck,... she's made
of wood.

>
Nice one :)

Har har!

>
--
Steven

[Aaron Brady]

Re: Finding the instance reference of an object

On Oct 31, 3:23 am, Steven D'Aprano <st...@REMOVE-THIS-
cybersource.com .auwrote:

On Thu, 30 Oct 2008 19:55:57 -0700, Aaron Brady wrote:

On Oct 30, 9:05 pm, Steven D'Aprano <st...@REMOVE-THIS-
cybersource.com .auwrote:

On Fri, 31 Oct 2008 13:58:13 +1300, greg wrote:
Dale Roberts wrote:

>

snip

>

If they understand how assignment works in Python, that tells them
all they need to know.

>

Nonsense.

>

Maybe I missed this part.  What does the phrase, "value of variable x"
mean in Python?  Is it the same as what it means in C, Pascal, etc.?

>

In other words,

>

>>x= [ 2, 3, 4 ]
>>'0x%x'%id( x )

'0xb39dd0'

>

What is the value of 'x'?
a) [ 2, 3, 4 ]
b) An object with contents [ 2, 3, 4 ]
c) 0xb39dd0
d) None of the above.

>
Solution a) is just shorthand for b), because there are (or at least
could be) many such objects [2, 3, 4]. So I'd accept either a) or b) as
reasonable answers.

snip

I'm actually going to take issue with this... not to beat a dead
horse. (a) and (b) are distinct, at least potentially, and Steven did
not supply the burden of proof necessary for answering more than one.

More specifically, I want a definition of what it means "to copy an
object onto the stack". If one wanted to say, "copy a reference to it
onto the stack", would one say it, necessarily and always? In other
words, can one infer from a fact that one didn't say the latter, that
one didn't mean it?

People just express themselves and don't always speak with
mathematical precision. But, doing so, an object is not the same as a
reference to it, and all Python does is pass and copy references.

In fact, observing that the equals sign is not a mutating operation,
I'd even hold that Python calls by reference.