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]] -- https://mail.python.org/mailman/listinfo/python-list