Modifying Class Object
in [Python]
|
From: Alf P. Steinbach on 8 Feb 2010 23:01 * Stephen Hansen -> Alf P. Steinbach: > > [snip] > To say, "pass by value" implies things to people. It describes a sort of > world where I'm a function about to do some work, and on my desk I have > a series of boxes with names on it. It describes an environment where > someone comes over and drops something into each of my boxes. The > contents of these boxes are mine alone! Then, when the imprecision makes people misunderstand, one should not say that. One should then be more precise. One should say /what/ is passed by value. [snip] > >>> import copy > >>> def doit(a): > ... a += a > ... return a > ... > >>> test1 = 1 > >>> test2 = doit(test1) > >>> test1 > 1 > >>> test2 > 2 > >>> test3 = [1] > >>> test4 = doit(test3) > >>> test3 > [1, 1] > >>> test4 > [1, 1] > > I know you already know this, but the point is: you're -hurting- other > peoples understanding by using terms like this that don't apply to > Python's specific nature. The terms apply very well to Java. And Java has the identical parameter passing mechanism for class type objects. Hence, the argument is bogus. Cheers & hth., - Alf PS: I cannot see any of your postings on Usenet. So I just sort of grabbed this from GMane and posted to Usenet. Hopefully you'll see it back at the list. :-)
From: Terry Reedy on 8 Feb 2010 23:25 On 2/8/2010 2:10 PM, Alf P. Steinbach wrote: > I apologize for assuming that "pointer" is a known word to [c.l.p.] > denizens. It is irrelevant. Python calls Python functions by associating argument objects (or objects derived therefrom) with paramenter names, very much like assigment statements. If one understands Python objects, names, and assignment statements, which one must to understand Python, this completely explains the function calls, function execution, and its effect on passed objects. All Python expressions evaluate to an object. Call expressions evaluate to the object returned by the function. Different interpreters implement call and return differently. Certainly, most humans do not use C pointers when they mentally execute Python code. Terry Jan Reedy
From: Alf P. Steinbach on 9 Feb 2010 00:12 * Terry Reedy: > On 2/8/2010 2:10 PM, Alf P. Steinbach wrote: > >> I apologize for assuming that "pointer" is a known word to [c.l.p.] >> denizens. > > It is irrelevant. > > Python calls Python functions by associating argument objects (or > objects derived therefrom) with paramenter names, very much like > assigment statements. Well, part of the above is word-play. When a name refers to an object elsewhere and that reference can be copied around, then it is a pointer to the object in e.g. the Java sense, which I very purposefully referenced to be clear about it. So you're saying that X is irrelevant in Python because Python uses Y, where Y is a description of X... But part of what you write puzzles me. As far as the language spec is concerned the argument passing mechanism seems to me to be identical to assignments, not just "very much like". Your phrase "or objects derived therefrom" seems to imply that immutable objects can be copied (an optimization that once was rejected), but as far as I can see the language spec only talks about binding with no provision for binding to do anything else than making a name refer directly to a specified object, presumably with *the same id*. Not talking about things built on top of argument passing like *, and not talking about scopes or other (in this context) extraneous details: is there something I've overlooked in the basic mechanism? > If one understands Python objects, names, and assignment statements, > which one must to understand Python, this completely explains the > function calls, function execution, and its effect on passed objects. Yes. There are many ways to understand it though. The simplest description, reality, that names refer to objects, where those references can be copied, i.e. that they in e.g. the Java sense are pointers to objects, seems to be simplest -- and is certainly shortest. :-) > All Python expressions evaluate to an object. Call expressions evaluate > to the object returned by the function. > > Different interpreters implement call and return differently. Certainly, > most humans do not use C pointers when they mentally execute Python code. The Java language spec reference for "pointer" was to avoid arguments about irrelevant specialized meanings of the term, such as C pointers. Cheers & hth., - Alf
From: Steven D'Aprano on 9 Feb 2010 00:38 On Tue, 09 Feb 2010 05:01:16 +0100, Alf P. Steinbach wrote: > * Stephen Hansen -> Alf P. Steinbach: >> >> [snip] >> To say, "pass by value" implies things to people. It describes a sort >> of world where I'm a function about to do some work, and on my desk I >> have a series of boxes with names on it. It describes an environment >> where someone comes over and drops something into each of my boxes. The >> contents of these boxes are mine alone! > > Then, when the imprecision makes people misunderstand, one should not > say that. > > One should then be more precise. > > One should say /what/ is passed by value. I don't see how that matters. Python's behaviour is EXACTLY the same, no matter what you pass to the function. You don't pass pointers in Python, because you, the Python author, have no way of specifying a pointer in Python code. It is *always* an object that you pass, by giving a literal, the name an object is bound to, or some other expression that returns an object: function( my_object ) function( 12345 ) function( ham(3) + spam(5) ) If you're talking to the person who writes Python code, then you should discuss the sorts of things that exist in Python: objects and names and expressions, but no pointers. If you're talking about the Python virtual machine, instead of the high- level Python code, then you should say so -- but there are still no pointers in the VM. Look at the output of dis.dis and you will see objects pushed onto a stack, but no pointers. It's not until you get past the level of Python code, past the virtual machine, and into the implementation of the virtual machine, that you will finally find pointers. But why stop there? If somebody asks you a question about Python, and you choose to ignore them and answer a different question about one particular implementation's internals instead, I don't see why you stop there. Why not go down another layer and talk about copying bytes, or two layers and answer that Python does call-by-bit-flipping, or a layer below that and say it's all done by varying potential differences? You shouldn't expect your listener to understand machine code to understand Python's high-level behaviour, nor should you expect them to be C coders. You don't need to understand pointers to understand a language that doesn't support them. [...] > The terms apply very well to Java. And Java has the identical parameter > passing mechanism for class type objects. Hence, the argument is bogus. Everything I've said applies to Java as well, and the argument about call- by-whatever is just as prevalent in Java circles as in Python. Example #1: Q: If Java uses the pass-by reference, why won't a swap function work? A: Your question demonstrates a common error made by Java language newcomers. Indeed, even seasoned veterans find it difficult to keep the terms straight. Java does manipulate objects by reference, and all object variables are references. However, Java doesn't pass method arguments by reference; it passes them by value. http://www.javaworld.com/javaworld/javaqa/2000-05/03-qa-0526-pass.html Example #2: Myth: "Objects are passed by reference, primitives are passed by value" Some proponents of this then say, "Ah, except for immutable objects which are passed by value [etc]" which introduces loads of rules without really tackling how Java works. http://www.yoda.arachsys.com/java/passing.html Example #3: Java is Pass-by-Value, Dammit! http://javadude.com/articles/passbyvalue.htm Java programmers suffer for a bad mental model just as much as Python programmers. All this is because of two conceptual mistakes: (1) the Java community has conflated the internals of what happens in the implementation of the Java VM with high-level Java code; and (2) a refusal to accept that there are calling strategies other than pass-by-value and pass-by-reference. -- Steven
From: Alf P. Steinbach on 9 Feb 2010 01:35
* Stephen Hansen: > On Mon, Feb 8, 2010 at 8:01 PM, Alf P. Steinbach <alfps(a)start.no > <mailto:alfps(a)start.no>> wrote: > > * Stephen Hansen -> Alf P. Steinbach: > > > [snip] > > To say, "pass by value" implies things to people. It describes a > sort of world where I'm a function about to do some work, and on > my desk I have a series of boxes with names on it. It describes > an environment where someone comes over and drops something into > each of my boxes. The contents of these boxes are mine alone! > > > Then, when the imprecision makes people misunderstand, one should > not say that. > > One should then be more precise. > > One should say /what/ is passed by value. > > > No. > > One should not use the phrase that is fundamentally imprecise. > > The phrase "pass by value" means something different then the phrase > "pass by object" aka "pass by sharing". They are in many cases very > similar. They are not the same. Right. "pass by value" is a lower level notion. And as you show below, in the paragraph marked [1], it can be used to describe call by sharing very succinctly and precisely, just as I did... ;-) > Using it is simply wrong. There is > really no legitimate argument you can make otherwise: even in languages > where call-by-value IS the norm, the phrase is imprecise enough to > confuse people, as the semantics of what call-by-value mean to a > language vary. But those semantics do NOT apply to Python. In a way that's right, but only at the level of abstraction of pass by sharing. At that level it's wrong to say that pass by sharing is pass by value (as they reportedly do over in Java-land), just as, at that level, it's wrong to say that pass by reference is pass by value notwithstanding that some kind of value must be copied in the internal implementation. Describing pass by sharing in terms of pass by value is however very simple and legitimate, involving a higher level described in terms of a lower level -- as you illustrate right below: <g> > [snip] > I know you already know this, but the point is: you're -hurting- > other peoples understanding by using terms like this that don't > apply to Python's specific nature. > The terms apply very well to Java. And Java has the identical > parameter passing mechanism for class type objects. Hence, the > argument is bogus. > > > [1] Java uses silly terminology; and that it chooses to use silly > terminology in no way impacts the validity of the argument. Java isn't > an authority. Python's been around longer! And the specific behavior > here, "call by value where the value is an object reference" was named > "call by sharing" back in the 1970's by Liskov. Yep. As you write, "call by sharing" can be described as "call by value where the value is an object reference". Althuogh I'd rather use "where the value is an object pointer", because the word "pointer" already denotes a copyable value so doesn't make the head spin... > Java isn't call-by-value (for objects) either, even if that phrase is > common in the Java community. Right, and here the parenthesis (for objects) establishes which abstraction level. > C is call-by-value. VB is, I believe, > call-by-value -- though I may be wrong here, as I only sort of blinked > at VB a long, long time ago. Full VB supports both call by sharing and call by reference. > Its distinct. Its different. Its neither call-by-value, nor > call-by-reference. The /value/ of a thing is NOT its identity. Its the > /state/ of that thing. Talking about a reference value (a.k.a. pointer), as you do earlier above in [1], does not mean that one is talking about a Python object value. So essentially the paragraph immediately above seems to be a confusion based on multiple meanings of "value", unless it's just a description of Python objects? > By your argument, call-by-reference is call-by-value too! Because you're > passing "a value" -- but you're -always- going to pass some piece of > data, otherwise you're not actually passing anything. No, whatever you think my argument is (no quote, so I'm left in the dark about that assumption) here you're back to confusing levels of abstraction again. Call by reference is necessarily, at some level, implemented in terms of call by value. That doesn't make call by reference the same as call by value, not more than the human body is one giant molecule just because it consists of molecules. > The /by value/ vs /by reference/ vs /by sharing/ is not about "is a > value being passed", in all cases, "a value" is. By Value means a copy > of the thing is made. By Reference means you're accessing the callers > variable directly. By Sharing means you're both sharing the same object. Yes, violent agreement. > PS: I cannot see any of your postings on Usenet. So I just sort of > grabbed this from GMane and posted to Usenet. Hopefully you'll see > it back at the list. :-) > > > I've heard that before, and have no idea why, nor any real interest in > solving it: I don't want to read cpl via Usenet, and prefer to read it > as a mailing list. Somewhere between Gmail->python.org->python.org > <http://python.org>'s usenet server->the world, some people don't seem > to get my posts. Yet it shows up on some news servers, not others. > > No idea. Nothing I know of can solve it. Not sure, but perhaps it's possible to mail directly to gmane? Cheers & hth., - Alf |