A question on modification of a list via a function invocation

[Steve D'Aprano]

On Thu, 17 Aug 2017 11:37 pm, Ben Bacarisse wrote:

> What goes wrong when someone thinks of Python as passing by value but
> the value of an expression is an object reference?

Lots.

Because even if people *think* about call by value where the value is an
invisible reference to the actual value, that's not how they talk, because it's
too hard. Look at Scott Stanchfield's extremely influential post. It is *not*
called:

"Java is call by value where the value is an invisible object reference,
dammit!"

http://javadude.com/articles/passbyvalue.htm

and consequently people who don't read or understand the *entire* post in full
take away the lesson that 

"Java is call by value, dammit!"

So how do we distinguish between languages like Java and Python and those like C
and Pascal which *genuinely* are call by value, and do exhibit call by value
semantics? For example, in Pascal, if you declare an array parameter without
specifying it as "var", the compiler will copy the entire array. Java does not
do that. Python does not do that.

C doesn't treat arrays as first class values, so you can't pass an array as
argument. You can only pass a pointer to the start of the array. But you can
declare arbitrarily big structs, and they are copied when you pass them to
functions. Java objects are not. Despite Scott's insistence that Java is
exactly the same as C, it isn't.

If we claim that Python is call by value, without specifying the proviso "if you
consider the value to be the invisible reference to the actual value" every
time, we risk misleading others into wrongly inferring that Python is "call by
value" and you shouldn't pass big lists to functions because then they will be
copied and that's inefficient.

Or people will be confused by the behaviour of Python, and decide that maybe it
is only call by value when you pass an immutable object like a string or int,
and is call by reference when you pass a mutable object like a list or dict.
Many people have done that.

Imagine this conversation:

* * *

"I was reviewing your code, and in module spam.py I don't understand what value
the x variable has."

"I don't know. It's something implementation dependent."

"What do you mean?"

"It depends on the interpreter. In CPython the value will be a pointer.
Something like an address 0x1234abcd."

"But Python doesn't have pointers."

"Okay, call it a reference then. Whatever the implementation uses to point to
objects."

"I don't care about the Python implementation, I want to know the value of x."

"I told you. It's some unknown and unknowable reference or pointer to an
object."

"Okay. Given x=1, what's the value of x?"

"How do I know? It depends on the implementation. Something like 0x93a80f16 I
guess. Why do you care about the value?"


* * * 

Obviously this isn't going to happen. Nobody actually thinks like this. Given
x=1, we all agree that the value of x is 1, not some invisible, unknown,
unknowable, implementation-dependent reference.

Instead they have to juggle two mutually contradictory meanings of value in
their head, and try to guess which one is meant at any point. Sometimes the
value of x is 1, and sometimes it is the invisible reference, and because that
is usually implied rather than explicit, there's always room for confusion and
misunderstanding.

This whole thing is unnecessary. It is no easier to learn that:

"Python is call by value, where the value is an invisible object reference"

than it is to learn that:

"Python is call by object sharing".

Either way, you have to learn what it means, otherwise it might as well be
gobbledygook:

"Python is whargle bargle by wazit, where the wazit is fizzbit wacker p'toing".


The terminology has been around for forty years. It was invented by Barbara
Liskov, one of the pioneers of OOP, the same person responsible for the Liskov
Substitution Principle. So its not like it is some obscure term invented
by "just some guy on the internet".



-- 
Steve
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.