On Sun, 3 Apr 2016 05:54 am, Random832 wrote: > On Sat, Apr 2, 2016, at 15:28, Ned Batchelder wrote: >> On Friday, April 1, 2016 at 4:27:30 PM UTC-4, Fillmore wrote: >> > notorious pass by reference vs pass by value biting me in the backside >> > here. Proceeding in order. >> >> As others have pointed out, this is false dichotomy. There are other >> possibilities than pass by reference and pass by value. Python (and >> many other languages) use something called pass by object or pass by >> sharing. > > I think that this arises from a confusion as to what a "value" is in > "pass by value".
I don't understand what you mean by this. Are you defending the idea that Python is pass-by-value, or saying that Fillmore is confused by what pass-by-value means, or something else? What precisely are you trying to say here? > The point of it being pass by value is that there is no statement you > can execute in the function that has the effect of an assignment of the > expression that was passed in from the caller. No, that alone is insufficient. There are other calling conventions that have the same effect. Pass-by-value also requires that the value being passed is copied. Unfortunately we've been plagued by a bunch of comp sci graduates who suffer from the "little bit of learning" problem. Having learned that there are only two calling conventions, pass by value and pass by reference, and correctly recognising that their language of choice is not pass by reference, they then jump through some remarkable intellectual contortions to prove that it is therefore pass by value. To do this, they normally redefine "value" to mean something other than what everyone else thinks of as the value being passed to a function. The Java community is especially prone to this: http://javadude.com/articles/passbyvalue.htm Note the author's definition of pass-by-value: [quote] Pass-by-value The actual parameter (or argument expression) is fully evaluated and the resulting value is copied into a location being used to hold the formal parameter's value during method/function execution. [end quote] That the value is *copied* is fundamental to pass by value semantics. The author, Scott Stanchfield, then claims that Java is pass by value. (Note: for this entire discussion, I'm referring to boxed values, or objects, not primitives. There's no dispute that Java is pass by value for primitives.) But to make this work, he has to use a bit of slight of hand: what gets copied in Java function calls is not the value of the argument, but some abstract reference to that value. There's this invisible abstract reference is the value of the variable. He doesn't come right out and say this, but if you read his description of what Java does, it should be obvious that he thinks of Java variables as being bound to abstract pointers or references rather than being bound to objects themselves. Consequently, if you bind a value to a variable name: String str = "Hello"; then to Stanchfield, the value of the string variable str is presumably not "Hello", but some unknown and unknowable abstract reference like 0x832fe50. This is the only way to make sense of his argument. Objects are not copied when you pass them to a function in Java, but the invisible reference to the object may be. Fredrik Lundh (the Effbot) quite rightly holds this view in scorn: [quote] I guess you can, in theory, value an artificial number assigned to an object as much as the object itself. "Joe, I think our son might be lost in the woods" "Don't worry, I have his social security number" [end quote] http://effbot.org/zone/call-by-object.htm Stanchfield's view of invisible references to objects being passed by value is, I have no doubt, right from the perspective of the Java implementation. Some would argue that he is "technically correct". But he is answering the wrong question. Calling Java (or Python) "pass by value" gives us no insight into how the language works. It is reductionism gone mad. Nobody, except maybe compiler designers, cares how the Java virtual machine implements argument passing. What Java developers care about is the behaviour of the Java language. Java's so-called "pass by value (where the value is some invisible reference to the value you actually care about)" behaves quite differently from pass by value in C, Pascal and others. Java doesn't copy objects when you pass them to functions. Nor does it pass references in pass by reference sense. Java objects are passed using the exact same semantics as Python objects, and neither pass by reference nor pass by value match that actual behaviour. Both languages provide an abstraction layer between the internal implementation details of the interpreter or virtual machine, and the high-level behaviour of the language. Stanchfield makes the same mistake with his claim that "Java has pointers", since of course it does not. The Java language gives you no way of creating such pointers to arbitrary chunks of memory (or to primitives), no way to dereference such a pointer if you had one (which you don't), and especially no way of advancing such (non-existent) pointers to the next record in memory. To put it another way, not only are pointers not first-class values in Java, they aren't values at all. There's no way to declare a variable of type "Pointer to Foo", or equivalent. So Stanchfield's claim that "Java has pointers" is, again, based on his conflating of values in the Java language compared to implementation details of the Java virtual machine. The JVM manages objects via indirect references to the object, and for that indirection, it may use some form of "thing which points to another thing": - C pointers (memory addresses); - some form of managed reference to a memory location; - classic Mac OS "handles" (managed pointers-to-pointers); - or even integer indexes into a giant array, like early versions of Fortran. But that hardly means that pointers are a feature of the Java language. > This holds no matter what > kind of object is passed in or what mutable properties it has or does > not have. I'm still not getting your point. -- Steven -- https://mail.python.org/mailman/listinfo/python-list