A question on modification of a list via a function invocation

[Rustom Mody]

On Thursday, August 17, 2017 at 6:49:19 AM UTC+5:30, Mok-Kong Shen wrote:
> Am 17.08.2017 um 02:41 schrieb Steve D'Aprano:
> > On Thu, 17 Aug 2017 08:29 am, Mok-Kong Shen wrote:
> > 
> >> I have earlier learned some other (older) programming languages. For
> >> these the formal parameters are either "by reference" or "by value".
> > 
> > By reference and by value are not the only two conventions.
> > 
> > Perhaps if you go back to the 1950s you might be able to argue that "reference"
> > and "value" are the only two conventions, but alternatives have existed for
> > many decades, since *at least* 1960 when Algol introduced "call by name".
> > 
> > Python's evaluation strategy has existed for at least 43 years since Barbara
> > Liskov named the calling convention used by CLU "call by sharing" in 1974.
> > 
> > (It actually is much older than CLU, it goes back all the way to Lisp.)
> > 
> > https://en.wikipedia.org/wiki/Evaluation_strategy#Call_by_sharing
> > 
> > 
> >> In the first case, any modification of the formal parameter
> > 
> > Technically, you cannot modify the formal parameter, because the formal
> > parameter is just a name unbound to any value. It's just the label in the
> > function definition. You need to have actually passed a value as argument to
> > the function before there is anything to modify.
> > 
> >> inside
> >> a function affects the corresponding actual parameter of a function
> >> call, while in the second case a copy of the actual parameter is
> >> passed into the function so that any modification of the formal
> >> parameter inside the function has no effect at all outside. This is
> >> extremely clear-cut in comparison to Python, isn't it?
> > 
> > Python (and Ruby, Scheme, Ocaml, etc) are very clear-cut too. Just different.
> > 
> > This may help:
> > 
> > http://import-that.dreamwidth.org/1130.html
> > 
> > 
> >> Anyway, while
> >> any new user of a programming language certainly can be expected to
> >> take good efforts to learn a lot of new stuffs, I suppose it's good
> >> for any practical programming language to minimize the cases of
> >> surprises for those that come from other programming languages.
> > 
> > Indeed. And call by value is surprising: why should passing a giant array of a
> > million values make a copy of the array just because I pass it to a function?
> > 
> > And call by reference is even more surprising: if I assign a value to a local
> > name inside a function, why should it modify names in the caller's namespace?
> > 
> > Python's evaluation strategy is the least surprising of all the calling
> > strategies I've used.
> 
> Sorry for my poor capacity to comprehend. I read in the web page you
> cited: "In Python, the parameters to a function or method are always
> local to that function or method. Any assignments to local variables
> inside the function only affect the local variable, not the caller's
> variable." But then why in my test2 the global list does get modified?
> (Would alist[0]=3 etc. be "in-place modification" while alist=[30,60,90]
> is deemed not an "in-place modification"? If yes, where is that term
> clearly defined? (That term is new for me.)

Let me offer you a non-standard (in the python world) view on the subject.
The fact that you are confused is good… it is in fact confusing!

What is called ‘call-by-object’ or ‘call-by-sharing’ etc is really an 
acknowledgement of the fact that parameter passing in the OO world along with
permissible mutation of data-structures is inherently leaky

Since this covers the large majority of modern languages, people wonder:
“Seriously?! Can ALL these languages be WRONG?”
Well… They are not wrong. Some things leak… Leakage is a fact of life

https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky-abstractions/
is written from a slightly different viewpoint but it applies here as well

And the best/only way you can come to grips with this is to understand
the pointer-patterns of linked data-structures

This is a bit of a delicate matter…
You dont need to know about machine addresses or allocation
But you do need to understand that the graphical or topological structure of 
b and c are different even if printing them shows no difference

>>> a = [1,2]
>>> b = [a,a]
>>> c = [[1,2],[1,2]]