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'

[Joe Strout]

On Oct 29, 2008, at 4:52 PM, Fuzzyman wrote:

You're pretty straightforwardly wrong. In Python the 'value' of a
variable is not the reference itself.

That's the misconception that is leading some folks around here into
tangled nots of twisty mislogic, ultimately causing them to make up
new terms for what every other modern language is perfectly happy
calling Call-By-Value.

I've thought a lot about why this misconception is so widespread here,
and I think it must be one of the following:

1. There was one community leader with this idea, who has been
successful at promoting it widely, much to the detriment of all; or,

2. Because everything in Python is an object, you're not forced to
think clearly (and more generally) about references as values as you
are in languages (such as Java, VB.NET, etc.) which have both simple
types and object types.

Either way, it's wrong (or at least, a needlessly complicated way of
looking at things).

.NET does draw a distinction between 'value types' and reference types
- where using reference types are called by reference (the reference
is passed) and value types are called by value (the value itself is
copied).

Quite right. Now, note that "ByRef" and "ByVal" apply to both.
Generalize to Python. There you go.

Best,
- Joe

P.S. I really am trying to quit responding to this thread. Sometimes
the urge is too strong. But I'll keep trying!

[Steve Holden]

Joe Strout wrote:

On Oct 29, 2008, at 4:52 PM, Fuzzyman wrote:

>You're pretty straightforwardly wrong. In Python the 'value' of a
variable is not the reference itself.

That's the misconception that is leading some folks around here into
tangled nots of twisty mislogic, ultimately causing them to make up new
terms for what every other modern language is perfectly happy calling
Call-By-Value.

I tried hard to make myself believe that the above was a clever pun and
knot [sic] a typo. Sadly I failed.

I've thought a lot about why this misconception is so widespread here,
and I think it must be one of the following:

1. There was one community leader with this idea, who has been
successful at promoting it widely, much to the detriment of all; or,

2. Because everything in Python is an object, you're not forced to think
clearly (and more generally) about references as values as you are in
languages (such as Java, VB.NET, etc.) which have both simple types and
object types.

How about

3. You just hate being wrong.

Either way, it's wrong (or at least, a needlessly complicated way of
looking at things).

One that has apparently served for almost twenty years now.

>.NET does draw a distinction between 'value types' and reference types
- where using reference types are called by reference (the reference
is passed) and value types are called by value (the value itself is
copied).

Quite right. Now, note that "ByRef" and "ByVal" apply to both.
Generalize to Python. There you go.

Best,
- Joe

P.S. I really am trying to quit responding to this thread. Sometimes
the urge is too strong. But I'll keep trying!

We must tax your patience dreadfully. I have suffered from the same
myself, but I fear we are doomed to pursue each other until Godwin's law
releases us.

Which reminds me, had you thought about submitting a paper along these
lines to PyCon? If we meet at PyCon at least let me buy you a pint to
show there are no hard feelings.

regards
Steve
--
Steve Holden [phone] [phone]
Holden Web LLC http://www.holdenweb.com/

[Fuzzyman]

On Oct 30, 1:13 am, Joe Strout <[e-mail]:

On Oct 29, 2008, at 4:52 PM, Fuzzyman wrote:

You're pretty straightforwardly wrong. In Python the 'value' of a
variable is not the reference itself.

That's the misconception that is leading some folks around here into
tangled nots of twisty mislogic, ultimately causing them to make up
new terms for what every other modern language is perfectly happy
calling Call-By-Value.

I've thought a lot about why this misconception is so widespread here,
and I think it must be one of the following:

1. There was one community leader with this idea, who has been
successful at promoting it widely, much to the detriment of all; or,

2. Because everything in Python is an object, you're not forced to
think clearly (and more generally) about references as values as you
are in languages (such as Java, VB.NET, etc.) which have both simple
types and object types.

But those languages clearly make the distinction between values and
references that you refuse to make! Go figure...

Michael

Either way, it's wrong (or at least, a needlessly complicated way of
looking at things).

.NET does draw a distinction between 'value types' and reference types
- where using reference types are called by reference (the reference
is passed) and value types are called by value (the value itself is
copied).

Quite right. Now, note that "ByRef" and "ByVal" apply to both.
Generalize to Python. There you go.

Best,
- Joe

P.S. I really am trying to quit responding to this thread. Sometimes
the urge is too strong. But I'll keep trying!

[Fuzzyman]

On Oct 30, 1:13 am, Joe Strout <[e-mail]:

On Oct 29, 2008, at 4:52 PM, Fuzzyman wrote:

You're pretty straightforwardly wrong. In Python the 'value' of a
variable is not the reference itself.

That's the misconception that is leading some folks around here into
tangled nots of twisty mislogic, ultimately causing them to make up
new terms for what every other modern language is perfectly happy
calling Call-By-Value.

I've thought a lot about why this misconception is so widespread here,
and I think it must be one of the following:

1. There was one community leader with this idea, who has been
successful at promoting it widely, much to the detriment of all; or,

2. Because everything in Python is an object, you're not forced to
think clearly (and more generally) about references as values as you
are in languages (such as Java, VB.NET, etc.) which have both simple
types and object types.

To make it clearer for you, call by value means that the value is
copied in - and therefore changes to the value won't be visible to the
caller.

In .NET this is true of mutable value types - changes made are made to
a copy and not visible to the caller. In Python we *only* have
reference types, so changes to *any* mutable object are visible to the
caller.

In .NET you can call by reference with a value type - and the runtime
does boxing for you so that you can see the changes. You have to
explicitly ask for call by reference though.

Michael

Either way, it's wrong (or at least, a needlessly complicated way of
looking at things).

.NET does draw a distinction between 'value types' and reference types
- where using reference types are called by reference (the reference
is passed) and value types are called by value (the value itself is
copied).

Quite right. Now, note that "ByRef" and "ByVal" apply to both.
Generalize to Python. There you go.

Best,
- Joe

P.S. I really am trying to quit responding to this thread. Sometimes
the urge is too strong. But I'll keep trying!

[Dale Roberts]

On Oct 29, 9:13*pm, Joe Strout <[e-mail]:

On Oct 29, 2008, at 4:52 PM, Fuzzyman wrote:

You're pretty straightforwardly wrong. In Python the 'value' of a
variable is not the reference itself.

That's the misconception that is leading some folks around here into *
tangled nots of twisty mislogic, ultimately causing them to make up *
new terms for what every other modern language is perfectly happy *
calling Call-By-Value.

Doesn't this logic also apply to Call By Reference? Isn't that term
redundant too? (see my 3 C++ examples above). If not, why not? 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 Object Reference" is an idiom, just like Call By Reference.
It is not a physical description of what is going on internally at the
register/stack level (which is always just shuffling values around -
or flipping bits, as Steven points out), it is a higher level concept
that helps people understand the *intention* (not necessarily the
implementation) of the mechanism.

You cannot look a C++ programmer straight in the eye and say that
"Python uses Call By Value, Period", without also informing them that
"Python variables can ONLY EVER hold object references - that is the
only "value" they can ever hold". Then the C++ programmer will go "Oh,
yea, that makes sense".

Instead of having to say all of that, we just give it a new name.
Instead of "Call By Value, Where Every Single Value Is Only Ever A
Reference To An Object Which Contains The Actual Value That
Programmers Usually Refer To", we just say "Call By Object Reference".

...
2. Because everything in Python is an object, you're not forced to *
think clearly (and more generally) about references as values

I think we've shown that we are all in fact thinking clearly about it,
and we all (you included, of course!) understand what is going on.
It's just a matter of what words we choose to describe it.

Using your definition of value, though, I believe that if you want to
throw out Call By Object Reference, you also have to throw out Call By
Reference. See my 3 C++ examples above. And just for fun I did look at
the assembler output, and, indeed, the output for examples 1 and 3 is
absolutely identical. They are the same thing, as far as the CPU is
concerned.

Would you give them different names?

dale

[Joe Strout]

On Oct 30, 2008, at 7:56 AM, Dale Roberts wrote:

>That's the misconception that is leading some folks around here into
tangled nots of twisty mislogic, ultimately causing them to make up
new terms for what every other modern language is perfectly happy
calling Call-By-Value.

Doesn't this logic also apply to Call By Reference? Isn't that term
redundant too? (see my 3 C++ examples above). If not, why not?

It's not. Wikipedia explains the difference pretty well.

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?

It's been a LONG time since I did anything in C, but yes, I believe
that reference parameters were an addition that came with C++.

"Call By Object Reference" is an idiom, just like Call By Reference.
It is not a physical description of what is going on internally at the
register/stack level (which is always just shuffling values around -
or flipping bits, as Steven points out), it is a higher level concept
that helps people understand the *intention* (not necessarily the
implementation) of the mechanism.

Right. And you can easily tell the difference, by whether an
assignment to the formal parameter causes any change to the actual
parameter that was passed in. If it does, that's call-by-reference.
If it doesn't, it's call-by-value. In Python, it doesn't. In VB.NET
(and relatives), it doesn't if the parameter is declared (explicitly
or implicitly) "ByVal", and does if it's declared "ByRef". (Whether
the parameter is a reference type or a simple value type makes no
difference.)

Python's behavior is exactly and always equivalent to the "ByVal"
behavior of languages that have both behaviors. It also matches the
definition of call-by-value. I quite agree that it's not helpful to
delve into the physical flipping of transistor states. We're talking
about the behavior, and the behavior, very clearly, is call-by-value.
To call it something else only clouds the issue and results in
confusion. (Perhaps explaining why there appears to be far more
confusion about call semantics in the Python community than in the
community of other languages where the default semantics are exactly
the same.)

Best,
- Joe

[Dale Roberts]

On Oct 30, 11:03*am, Joe Strout <[e-mail]:

...

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

It's been a LONG time since I did anything in C, but yes, I believe *
that reference parameters were an addition that came with C++.

Okay, I completely understand you, and I think we will just have to
agree to disagree about the best term to use for Python's parameter
passing mechanism, and this will likely be my concluding post on this
topic (although I have enjoyed it very much and have solidified my own
understanding).

I even found a few web sites that very strongly support your viewpoint
(as it relates to Java):

http://www.ibm.com/developerworks/li...raxis/pr1.html
http://javadude.com/articles/passbyvalue.htm
http://www.yoda.arachsys.com/java/passing.html

The difference is that I would say that C supports the Pass By
Reference idiom using this syntax:

myfunc(int *val){} /*CALL:*/ myfunc(&i);

which actually passes an address expression (not a variable) by value,
but "looks and feels" like a reference to the "i" variable, which
contains the real value that we care about - and allows modification
of that value.

C++ adds a syntactic change for this very commonly used C idiom, but
does not add any new capability - the results are absolutely
indistinguishable.

Python, likewise, in relation to the values we care about (the values
contained only in objects, never in variables) behaves like Call by
Object Reference.

If I tell someone that Python uses only Call By Value (and that is all
I tell them), they may come away with the impression that variables
contain the values they care about, and/or that the contents of
objects are copied, neither of which is the case, even for so-called
"simple", immutable objects (indeed, at the start of this thread, you
said you believed that, like Java, simple values were contained within
Python variables).

But Python, unlike Java or most other commonly used languages, can
ONLY EVER pass an object reference, and never an actual value I care
about, and I think that idiom deserves a different name which
distinguishes it from the commonly accepted notion of Pass By Value.

Thanks for a thoughtful discussion,
dale

[Dale Roberts]

On Oct 30, 3:06*pm, Dale Roberts <[e-mail]:

... that idiom deserves a different name which
distinguishes it from the commonly accepted notion of Pass By Value.

Bah, what I meant to end with was:

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

Again, thanks for the discussion,
dale

[greg]

Douglas Alan wrote:

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

>>Seems to me that (1) describes exactly how parameter passing
works in Python. So why insist that it's *not* call by value?

Because there's an important distinction to be made,

The distinction isn't about parameter passing, though, it's
about the semantics of *assignment*. Once you understand
how assigment works in Python, all you need to know then
is that parameters are passed by assigning the actual
parameter to the formal parameter. All else follows from
that.

This holds for *all* languages that I know about, both
static and dynamic. Once you know how assignment works in
the language concerned, then you know how parameter
passing works as well. There is no need for new terms.

and the
distinction has been written up in the Computer Science literature
since Lisp first starting using the same argument passing semantics as
Python back in 1958. The semantics are called "call by sharing".

I still think it's an unnecessary term, resulting from
confusion on the part of the authors about the meanings of
the existing terms.

If there's any need for a new term, it would be "assignment
by sharing". Although there's already a term in use for that,
too -- it's known as reference assignment.

Many mainstream programming languages other than Python now use call
by sharing. They include Java, JavaScript, Ruby, ActionScript, and C#.

I would say they use assignment by sharing, and call by
value.

--
Greg

[greg]

Gabriel Genellina wrote:

En Tue, 28 Oct 2008 00:58:10 -0200, greg <gr**@cosc.canterbury.ac.nz>
escribió:

>(1) Call by value: The actual parameter is an expression. It is
evaluated and the result is assigned to the formal parameter.
Subsequent assignments to the formal parameter do not affect
the actual parameter.

(2) Call by reference: The actual parameter is an lvalue. The
formal parameter becomes an alias for the actual parameter,
so that assigning to the formal parameter has the same
effect as assigning to the actual parameter.

Those definitions are only applicable to unstructured, primitive types,
where the only relevant operations are "get value" and "assign value".
Structured types provide other operations too - like selection
(attribute get/set in Python).

But that isn't what "assigning to the formal parameter" means --
it only means assigning directly to the parameter *name*.

It is unspecified on both definitions
above what happens in those cases.

That's true, but it's outside the scope of the parameter passing
mechanism to define what happens in those cases. That's down to
the data model being used by the language and the semantics of
assignment in general.

--
Greg

[greg]

Dale Roberts wrote:

Okay, you can have it that way, but every time you explain to someone
that Python passes "By Value", you will have to add the additional
baggage that, oh, by the way, there is a completely different meaning
for "value" in Python than what you are used to.

For what it's worth, I happen to agree that telling
someone that Python passes parameters "by value" without
being sure they understand exactly what "by value"
means, is not a good idea -- not because the term
isn't well-defined, but because of the widespread
confusion out there about it.

But equally I wouldn't tell someone that it's *not*
by value, because if they do happen to correctly
understand what it means, that will confuse them just
as much.

So my recommendation is just to tell them that it
works by assigning the result of evaluating the actual
parameter to the formal parameter.

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

If they don't understand how assignment works, then they
have a more fundamental knowledge gap that needs to be
corrected first.

--
Greg

>
Then the questions and puzzled looks will start...

And when they tell their friend that Joe The Programmer said it's Pass
By Value, your additional context may not be present any longer, and
the friend will be very confused.

In my opinion, best just to head it off and call it something
different so as not to confuse.

dale

[Steven D'Aprano]

On Thu, 30 Oct 2008 09:03:42 -0600, Joe Strout wrote:

Python's behavior is exactly and always equivalent to the "ByVal"
behavior of languages that have both behaviors.

Pascal has both ByVal and By Ref, and Python's behaviour is absolutely
not the same as Pascal's ByVal.

It also matches the definition of call-by-value.

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.

I quite agree that it's not helpful to
delve into the physical flipping of transistor states.

Nor is it helpful to delve into the implementation details of pointers
and references. There are no such things in Python code, and the Python
virtual machine doesn't see them. Only the underlying implementation sees
them, and as Fuzzyman has already explained, the .Net implementation of
IronPython differs from the C implementation of CPython, and this has
real consequences for Python code exposed to .Net objects.

We're talking
about the behavior, and the behavior, very clearly, is call-by-value.

Only if you redefine c-b-v to something that it unrecognizable to anyone
else.

Joe, you've got a cheek sneering at us for inventing new terms (that we
didn't in fact invent, that have a long history in the IT field, one
involving such giants as Barbara Liskov) when your entire argument rests
on the hijacking of the word "value" to mean "some arbitrary,
implementation-dependent reference to the thing which is the actual
value".

It is an abuse of language and common sense to claim that after executing
x=42, the "value" of x is 149605700 (or whatever arbitrary memory
location you happen to get). That nonsensical idea is the bedrock of your
entire argument.

--
Steven

[Steven D'Aprano]

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

Dale Roberts wrote:

>Okay, you can have it that way, but every time you explain to someone
that Python passes "By Value", you will have to add the additional
baggage that, oh, by the way, there is a completely different meaning
for "value" in Python than what you are used to.

For what it's worth, I happen to agree that telling someone that Python
passes parameters "by value" without being sure they understand exactly
what "by value" means,

"By value" is very simple. It means a copy of the value is passed to the
function.

Using "call by value" to mean "pass a copy of a reference to the value"
is an abuse of terminology, because that's exactly what happens in call
by reference: a copy of the reference to the value is passed.

is not a good idea -- not because the term isn't
well-defined, but because of the widespread confusion out there about
it.

Well duh. All these people trying to insist that after executing x=1 the
value of x is some arbitrary memory location are certainly confused.

But equally I wouldn't tell someone that it's *not* by value, because if
they do happen to correctly understand what it means, that will confuse
them just as much.

But it isn't call by value. Why wouldn't you tell people it is when the
value isn't being copied?

So my recommendation is just to tell them that it works by assigning the
result of evaluating the actual parameter to the formal parameter.

And 99% of them will just say "What?".

That's not an explanation, it's obfuscation at its worst. What *is* the
result of evaluating the actual parameter? Is it a reference to the
object or the object itself? Is it a copy of the object? A shallow copy?
A deep copy? Not a copy at all? What implications for behaviour does it
have? What does it mean?

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

Nonsense.


--
Steven

[Aaron Brady]

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.

I hold that the burden of proof is yours if you hold that there is
more than one answer.

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.

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

[Joe Strout]

On Oct 30, 2008, at 6:38 PM, greg wrote:

The distinction isn't about parameter passing, though, it's
about the semantics of *assignment*. Once you understand
how assigment works in Python, all you need to know then
is that parameters are passed by assigning the actual
parameter to the formal parameter. All else follows from
that.

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

Just to be complete, it only holds in "ByVal" mode (for languages that
have both ByVal and ByRef modes, like VB.NET). A call-by-value
parameter pass is equivalent to an assignment to the formal parameter,
as you say. A call-by-reference parameter is not.

This is yet another simple way to see what type of parameter passing
Python uses.

Once you know how assignment works in
the language concerned, then you know how parameter
passing works as well. There is no need for new terms.

Agreed.

Best,
- Joe

[Joe Strout]

On Oct 30, 2008, at 6:58 PM, greg wrote:

For what it's worth, I happen to agree that telling
someone that Python passes parameters "by value" without
being sure they understand exactly what "by value"
means, is not a good idea -- not because the term
isn't well-defined, but because of the widespread
confusion out there about it.

But equally I wouldn't tell someone that it's *not*
by value, because if they do happen to correctly
understand what it means, that will confuse them just
as much.

So my recommendation is just to tell them that it
works by assigning the result of evaluating the actual
parameter to the formal parameter.

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

If they don't understand how assignment works, then they
have a more fundamental knowledge gap that needs to be
corrected first.

That's a very sensible stance. +1!

Best,
- Joe

[Douglas Alan]

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

Douglas Alan wrote:

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

>>>Seems to me that (1) describes exactly how parameter passing
works in Python. So why insist that it's *not* call by value?

Because there's an important distinction to be made,

The distinction isn't about parameter passing, though, it's about
the semantics of *assignment*. Once you understand how assigment
works in Python, all you need to know then is that parameters are
passed by assigning the actual parameter to the formal
parameter. All else follows from that.

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. These languages generally don't use
these same semantics for assignment.

All languages that I know of that use call-by-sharing also do
assignment-by-sharing. Not all languages that do
assignment-by-sharing always do only call-by-sharing, however. For
instance, most dialects of Lisp have procedural macros. The calling
semantics of procedural macros are quite different from the calling
semantics of normal functions, even though procedural macros are Lisp
functions. Other dialects of Lisp provide the ability to state that
certain function arguments won't be evaluated at call time. All
dialects of Lisp, however, do assignment-by-sharing, or "binding" as
it is called in the Lisp community.

Also, one could certainly invent additional languages that do behave
in the typical manners.

If you are merely asserting, however, that understanding how Python
does assignment will help you understand how Python does argument
passing, then you are certainly correct. This, however, does not
imply that there is not a pre-existing precise terminology to describe
Python's calling semantics, and that this term can be useful in
describing how Python works.

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.

Once you know how assignment works in the language concerned, then
you know how parameter passing works as well. There is no need for
new terms.

This is simply not true.

>and the distinction has been written up in the Computer Science
literature since Lisp first starting using the same argument
passing semantics as Python back in 1958. The semantics are called
"call by sharing".

I still think it's an unnecessary term, resulting from confusion on
the part of the authors about the meanings of the existing terms.

Trust me, Barbara Liskov was not one bit confused when she invented
the term "call-by-sharing". And her language CLU was one of the most
prescient to have ever been designed and implmented.

If there's any need for a new term, it would be "assignment by
sharing". Although there's already a term in use for that, too --
it's known as reference assignment.

Reference assignement doesn't imply that the object is allocated on a
heap, and "call-by-sharing" does.

>Many mainstream programming languages other than Python now use call
by sharing. They include Java, JavaScript, Ruby, ActionScript, and C#.

I would say they use assignment by sharing, and call by value.

We can also argue about how many angels can dance on the head of a
pin, but the term "call-by-sharing" has been around since the 70s, and
it is already well-defined and well understood.

|>oug

[greg]

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

Pascal has it (using "var"), VB.NET has it (using "ByRef"),
C++ has it (using "&"). C does not have it, because there is
no syntax in the language for it. Neither does Python.

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.

You cannot look a C++ programmer straight in the eye and say that
"Python uses Call By Value, Period", without also informing them that
"Python variables can ONLY EVER hold object references - that is the
only "value" they can ever hold".

But he had darn well better learn that anyway, otherwise he's
going to have massive problems programming in Python that
don't have anything to do with parameter passing!

--
Greg

[greg]

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

[greg]

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. This does not happen
in Python, therefore there is no reason to suppose that it
will happen when passed as a parameter.

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.

--
Greg

[greg]

Steven D'Aprano wrote:

"By value" is very simple. It means a copy of the value is passed to the
function.

It only means that if you understand "copy" to mean
whatever it is that happens when you perform an assignment.
In Python, the term "copy" tends to imply rather more
than that, so you go off the rails using that definition.

>So my recommendation is just to tell them that it works by assigning the
result of evaluating the actual parameter to the formal parameter.

That's not an explanation, it's obfuscation at its worst.

I didn't necessarily mean to use those exact words. The
essential point is that you explain parameter passing in
terms of assignment.

What *is* the
result of evaluating the actual parameter? Is it a reference to the
object or the object itself?

It doesn't matter! All that matters is that they understand
what happens when you assign it to a name. You can explain
that using whatever terminology you want, as long as they
end up with a mental model that works. Then you tell them
that passing a parameter is just like doing an assignment.

I can't think what could be simpler or less obfuscatory
than that.

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

Nonsense.

Why? What else *do* you think they need to know?

--
Greg

[greg]

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!

--
Greg

[greg]

Douglas Alan wrote:

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

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

What I mean is that in all languages I know of that have
by-value or by-reference or both, they behave according to
the definitions I gave. If anyone has a counterexample,
I'll be interested to hear about it.

For
instance, most dialects of Lisp have procedural macros. The calling
semantics of procedural macros are quite different from the calling
semantics of normal functions

Yes, but nobody refers to that as either by-value or
by-reference as far as I know. Lisp people would probably
talk about the parameter being passed either "evaluated"
or "unevaluated".

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.

--
Greg

[greg]

Steven D'Aprano wrote:

Using "call by value" to mean "pass a copy of a reference to the value"
is an abuse of terminology, because that's exactly what happens in call
by reference: a copy of the reference to the value is passed.

No, it's not a reference to a value, it's a reference to
a *variable* (what C calls an lvalue). There is no such
thing as a reference to an lvalue in Python.

The presence of the word "reference" in "call by
reference" is another nasty terminology collision,
because it has nothing to do with what's called a
"reference" in Python.

The historical choice of terms is somewhat unfortunate.
If they'd been called something like "call by assignment"
and "call by alias", none of this confusion would have
arisen.

--
Greg

[Steven D'Aprano]

On Fri, 31 Oct 2008 20:15:30 +1300, greg wrote:

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!

This would make sense if Python was the only computer language in
existence, but it isn't. Consequently people who know these other
languages come along and ask "So is Python call by value or call by
reference?".

The correct answer to that is "No", but unfortunately there are far too
many people who refuse to accept the existence of any third parameter
passing mechanism and therefore confuse the issue by hammering the round
peg of Python's calling mechanism into the square hole of their pre-
conceptions. Depending on those particular pre-conceptions, they will
insist that Python "clearly and obviously is call by reference", or that
it is "clearly and obviously call by value, where the values are
references".
--
Steven

[Bruno Desthuilliers]

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]

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]

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]

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

--
Arnaud

[Grant Edwards]

On 2008-10-31, greg <gr**@cosc.canterbury.ac.nzwrote:

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]

On Oct 31, 3:15*am, greg <[e-mail]:

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 <[e-mail]:

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]

On Oct 31, 2:27*am, greg <[e-mail]:

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]

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]

pj********@googlemail.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]

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

Douglas Alan wrote:

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

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

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]

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

pj********@googlemail.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]

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]

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]

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.

[Steven D'Aprano]

On Sun, 02 Nov 2008 13:23:11 -0800, Aaron Brady wrote:

But, doing so, an object is not the same as a reference to it, and all
Python does is pass and copy references.

No, that's what at least one particular implementation of Python does.
That's not what Python does. The Python VM doesn't have any concept of
"values" or "references" or "values which are actually references in
disguise". The Python VM knows about *names in namespaces* and *objects*.

--
Steven

[Aaron Brady]

On Nov 2, 10:13*pm, Steven D'Aprano
<[e-mail]:

On Sun, 02 Nov 2008 13:23:11 -0800, Aaron Brady wrote:

But, doing so, an object is not the same as a reference to it, and all
Python does is pass and copy references.

No, that's what at least one particular implementation of Python does.
That's not what Python does. The Python VM doesn't have any concept of
"values" or "references" or "values which are actually references in
disguise". The Python VM knows about *names in namespaces* and *objects*.

--
Steven

I think we can conclude that Python passes by reference, since a
function can modify objects that were passed in to it.

[Marc 'BlackJack' Rintsch]

On Mon, 03 Nov 2008 15:27:01 -0700, Joe Strout wrote:

On Nov 3, 2008, at 2:36 PM, Aaron Brady wrote:

>Python can do the swap operation on mutable types, for example.

That's in the "no fair" category. C can do a swap operation on mutable
types, too, though it also has only pass-by-value. Same for Java, or
for REALbasic or VB.NET using "ByVal" mode. The fact that you can
mutate mutable types has absolutely nothing to do with whether the
parameter was passed by reference or value. If was by reference, you
can change it (the parameter itself, not something the parameter may
refer to). If it's by value, you can't.

In Python, you can't. That's because parameters are passed by value.

This conclusion is flawed because call-by-value is not the only parameter
passing style with that characteristics.

>By-Value and By-Reference are not the only passing methods. True or
False?

True, but the others are rarely used and don't apply to any of the
languages we've been discussing.

Maybe this is a surprise for you, because we haven't discussed this in
much detail in this group lately, but it applies to Python which does
call-by-object or call-by-sharing. ;-)

Ciao,
Marc 'BlackJack' Rintsch

[Steven D'Aprano]

On Mon, 03 Nov 2008 15:27:01 -0700, Joe Strout wrote:

>By-Value and By-Reference are not the only passing methods. True or
False?

True, but the others are rarely used and don't apply to any of the
languages we've been discussing.

Yeah, uncommon, rare languages that nobody uses, like Java, Lisp and
Python.


--
Steven

[Joe Strout]

On Nov 3, 2008, at 5:27 PM, Marc 'BlackJack' Rintsch wrote:

Maybe this is a surprise for you, because we haven't discussed this in
much detail in this group lately, but it applies to Python which does
call-by-object or call-by-sharing. ;-)

There's no such thing. Those are just terms made up by the Python
community to in place of the more standard "call-by-value" terminology
to make Python seem more mysterious than it really is. I guess you
can call it "purple bananas" if you want, but the behavior is exactly
the same as what every other language calls call-by-value.

But I really am trying not to continue this debate. So that's my last
reply about it for tonight, I promise. :)

Cheers,
- Joe
<http://www.strout.net/info/coding/valref/>

[Aaron Brady]

On Nov 3, 8:33*pm, Joe Strout <[e-mail]:

On Nov 3, 2008, at 5:27 PM, Marc 'BlackJack' Rintsch wrote:

Maybe this is a surprise for you, because we haven't discussed this in
much detail in this group lately, but it applies to Python which does
call-by-object or call-by-sharing. *;-)

There's no such thing. *Those are just terms made up by the Python *
community to in place of the more standard "call-by-value" terminology *
to make Python seem more mysterious than it really is. *I guess you *
can call it "purple bananas" if you want, but the behavior is exactly *
the same as what every other language calls call-by-value.

But I really am trying not to continue this debate. *So that's my last *
reply about it for tonight, I promise. *:)

Cheers,
- Joe
<http://www.strout.net/info/coding/valref/>

Here is the link to Barbara Liskov's paper, 1992, linked on
effbot.org.

"...arguments are passed "by object"; the (pointer to the) object
resulting
from evaluating the actual argument expression is assigned to the
formal."

http://publications.csail.mit.edu/lc...LCS-TR-561.pdf

However a Google search for "call by object", in quotes, returns
mostly Python-related links, which I find somewhat suspicious.

The search for call by sharing was more successful:

" 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.... if a routine assigns an object to a formal argument
variable, there is no effect on the caller."

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

That's an accurate description of Python. If VB.NET does the same
thing, I'll just assume that the designers named their keyword "ByVal"
instead of "ByShare", either to accommodate immutable primitives
(numbers), or to keep the keyword short.

[Hendrik van Rooyen]

"Aaron Brady" <ca********@gmail.comwrote:

>I think we can conclude that Python passes by reference, since a
function can modify objects that were passed in to it.

Sort of - if the modification is by "side effect" - so you
can append to a list, for instance.

However, if you use the passed param name on the left
of an assignment statement, you get a new local object.
I think it is this that lies at the root of the confusion.

- Hendrik

[Steven D'Aprano]

On Mon, 03 Nov 2008 19:33:52 -0700, Joe Strout wrote:

On Nov 3, 2008, at 5:27 PM, Marc 'BlackJack' Rintsch wrote:

>Maybe this is a surprise for you, because we haven't discussed this in
much detail in this group lately, but it applies to Python which does
call-by-object or call-by-sharing. ;-)

There's no such thing. Those are just terms made up by the Python
community to in place of the more standard "call-by-value" terminology
to make Python seem more mysterious than it really is.

I call bullshit on you. We've already shown you that the term call-by-
sharing (a.k.a. call-by-object or call-by-object-sharing) goes back to
the 1970s and such computer scientists as Barbara Liskov. The language
CLU used the term back in 1974, and it is possible that CLU wasn't the
first language to use it. That's over fifteen years before the first
release of Python.

This is not the first time it's been pointed out to you. And it won't be
the last. And I predict that it will make no difference to you at all:
you will still continue to pretend that Liskov et al aren't even worth
acknowledging, and you will continue to make the asinine definition that
the "value" of x following "x = 1" is 0x97b3250 rather than 1.

I guess you can
call it "purple bananas" if you want, but the behavior is exactly the
same as what every other language calls call-by-value.

Again, I call bullshit. Python's behaviour is not the same as what
Pascal, or C, calls call-by-value. It is what many Java people call "call-
by-value", because they make the same idiotic definition that the value
of a variable is some arbitrary and hidden reference to the thing of
interest:

"Java is call-by-value, where value means a reference to the actual
value, except for primitives, where the value is the actual value."

It is an idiotic definition, the sort of thing that only a very smart
person can make, twisting the plain and intuitive meaning of value ("what
is denoted by a symbol") just to avoid having to accept that there are
more things in reality than their pet theory includes.

It's not we Python folk who are guilty of misusing terminology, it is you
and your fellow VB and Java folk who are misusing the term call-by-value
to describe something which is nothing like call-by-value in Pascal and
C. There is a simple test you can do: pass a value to a function, and
have the function mutate that value. If the mutation appears in the
caller's environment, then the value wasn't copied and it is not call-by-
value. In Python:

def mutate(alist):
alist.append(1)

L = [1, 2]
mutate(L) # supposedly call by value
assert L == [1, 2]

If the assert statement fails (and it does), then no copy was made and
Python is not call-by-value.

So Python is not call-by-value, and it's not call-by-reference, so ...
either Python doesn't exist, or it uses a different calling convention.
--
Steven

[Craig Allen]

>

If the assert statement fails (and it does), then no copy was made and
Python is not call-by-value.

So Python is not call-by-value, and it's not call-by-reference, so ...
either Python doesn't exist, or it uses a different calling convention.

coming from C/C++ Python seemed to me call by reference, for the
pragmatic reason you said, modificaitons to function arguments do
affect the variable in the caller. The confusing part of this then
comes when immutable objects are passed in. You still get a reference,
but rather than complaining if you change the value of that parameter
at might happen if immutible was "const" and the code was const-
correct. Honestly I understand how this can change the callBy paradigm
I don't see it that way (though I've duly remembers call-by-sharing
and call-by-object) for communication purposes). I see it as a factor
of the way variable names are rebound, that is, the "quirk" I remember
is not about how entities are passed to functions, but the quirk of
how python deals with modifications to "immutibles".

That is, python lets you change object references pointing to
immutibles, which looks like changing the value referenced, by
rebinding.

So is that objectionable?

[Mel]

Craig Allen wrote:

That is, python lets you change object references pointing to
immutibles, which looks like changing the value referenced, by
rebinding.

So is that objectionable?

OK once in a while, but it wouldn't do for everyday.

Python 2.5.2 (r252:60911, Jul 31 2008, 17:28:52)
[GCC 4.2.3 (Ubuntu 4.2.3-2ubuntu7)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
# Case A:

>>a=2
b=3
a+b

5
# Case B:

>>id(a)

135720748

>>id(b)

135720736

>>id(a+b)

135720712

>>id(a)+id(b)

271441484

In talking about Python programs, we'd really like to talk like case A.
Meaningful values are tagged with names, passed around, operated on. We
get our result and leave. Case B adds a level of indirection that, if we
mention it, just obscures our actual task of summing two numbers.

Consider the fragment

def f (x, y):
return x+y
a=2
b=3
c = f(a, b)

We can imagine a cross-namespace assignment operator (which we could write
=\= if we needed more weird glyphs.) It works exactly like ordinary
assignment except that the LHS is evaluated in a different namespace from
the RHS. We could use our new operator to trace the execution of this code
fragment. The core of it would be

x =\= a # outer to inner assignment
y =\= b
c =/= x+y # inner to outer assignment

It's ordinary assignment all the way, except for being from an outer to an
inner, or from an inner to an outer namespace. Note how changing to
mutable arguments makes no difference (literal arguments this time):

c = f ([2], [3])

x =\= [2]
y =\= [3]
c =/= x+y

Replacing =\= and =/= with = loses us our cross-namespace conceit, but the
code still runs and does what Python code does.

So why import the wrong terminology from some other field, then try to save
it by mangling the definition of 'value' so that it's no use in discussing
what a program is supposed to do?

ob: Python, I refer you to the _Beyond the Fringe_ sketch "Portrait from
Memory", a reminiscence by a pseudo Bertrand Russell ("Moore, have you some
apples in that basket?".) You want to have to talk like this all the time?
See what I mean?