On Fri, 07 Nov 2008 08:48:19 -0700, Joe Strout wrote: > I think of it this way: every variable is an object reference; no > special syntax needed for it because that's the only type of variable > there is. (Just as with Java or .NET, when dealing with any class type; > Python is just a little more extreme in that even simple things like > numbers are wrapped in objects.) > > Note: I tried to say "name" above instead of "variable" but I couldn't > bring myself to do it -- "name" seems to generic to do that job. Lots > of things have names that are not variables: modules have names, classes > have names, methods have names, and so do variables.
But modules, classes and methods are also objects, and they can be bound to names. What's the name of the module after this piece of code? import math foo = math del math Unfortunately, the term "name" is *slightly* ambiguous in Python. There are names, and then there are objects which have a name attribute, which holds a string. This attribute is usually called __name__ but sometimes it's called other things, like func_name. The __name__ attribute of objects is an arbitrary label that the object uses for display purposes. But names are the entities that Python code usually uses to refer to objects. [...] > what > argument is there that the Python community should use its own unique > terminology for concepts that apply equally well to other languages? > Wouldn't communication be easier and smoother if we adopted standard > terms for standard behavior? You're assuming that call-by-sharing isn't a standard term. That's not true. It's a standard term that is sadly not well known, I believe because of the ignorance of most coders to the history of their own discipline. (I include myself in that.) You're also assuming that the use of "call-by-value" to refer to very different behaviours in C and Java somehow makes communication easier and smoother. I don't think it does. [...] > In a language that supports > integers and doubles as simple types, stored directly in a variable, > then it is an obvious generalization that in the case of an object > type, the value is a reference to an object. How is it a generalization? Using Python syntax instead of Java, but let's pretend that Python ints are primitives just like in Java, but floats are not. I do this to avoid any confusion over mutable/immutable, or container types. Nice simple values, except one is an object and one is a primitive type. x = 1 # the value of x is 1 x = 1.0 # the value of x is 0x34a5f0 Where is the generalization that you speak of? In a generalization, you extend the same rule to cover slightly different circumstances. But that's not what happens here. In the first place, you start with the rule that the value of x is the thing you assign to x. In the second place, you change the rule to say that the value of x is an arbitrary implementation-dependent pointer to the thing you assign to x. That's not a generalization, it's an anti-generalization. > But Python doesn't have those simple types, so there is a temptation > to try to skip this generalization and say that references are not > values, but rather the values are the objects themselves (despite the > dereferencing step that is still required to get any data out of > them). What dereferencing step? There's no such thing in Python code. You just use the name, as normal. Oh sure, at the deep implementation level there's a dereferencing step, but that applies for primitive types in C too. When you refer to a variable x in C, the CPU has to look into a memory location to find out what the value of x is. That applies whether x is an int on the stack or a object in the heap. But it's not something that the C programmer has to worry about, it's an implementation detail handled by the compiler and the runtime environment. It's not part of your C program. In the same way the dereferencing of Python names is not part of your Python program. It's an implementation detail. > However, it seems to me that when you start denying that the value of > an object reference is a reference to an object, this is when you get > led into a quagmire of contradictions. Let's hear some of these contradictions. Personally, they would have to be pretty big to make me give up saying that the value of x after x=1 is 1. [...] > But continuing to attempt to gloss over that fact, when you come to > parameter passing, you're then stuck trying to avoid describing it as > call by value, since if you claim that what a variable contains is the > object itself, then that doesn't fit (since clearly the object itself > is not copied). Your reasoning is backwards. Call-by-value by definition implies that the value is copied. If the value isn't copied, it can't be call-by-value. You shouldn't change the definition of "value" in order to hammer the square peg of your language into the round hole of "call-by-value", especially since there has been a perfectly fine alternative name for the behaviour since at least 1974. What the Java and VB.NET communities have essentially done is redefine "horse" to mean "internal combustion engine" simply to avoid accepting that there are such things as horseless carriages. > You also have to describe the assignment operator as > different from all other languages, since clearly that's not copying > the object either. A slight pedantic note: Python doesn't have an assignment operator, it is a statement. You can't override assignment in Python. *If* somebody reliably told me that assignment in "all other languages" (what, Forth, Lisp, Brainf*ck, Intercal, Algol-60, Ruby, *all* of them???) meant copying, then I'd quite happily accept that Python assignment is different, since it clearly doesn't copy the value. Assignment in Python operates on *names*, not objects. "x=y" means "change the name 'x' so that it refers to the current value of 'y'", not copy the value of y to x. > So, while I'm trying this path on for size (and will continue to mull > it over further), please try on this approach: boldly admit that > they're [variables] references, and embrace that fact. Why on earth would I want to give up saying that the value of x after x=1 is 1 just to satisfy people who can't cope with the existence of horseless carriages? > Perhaps we could > round up 20 newbies, divide them into two groups of 10, give each one > a 1-page explanation either based on passing object references by- > value, or passing values sort-of-kind-of-by-reference, and then check > their comprehension by predicting the output of some code snippets. > That'd be very interesting. It's hard for me to believe that the > glossing-over-references approach really is easier for anybody, but > maybe I'm wrong. Well Joe, you've seen for yourself at least one person in this thread read YOUR explanation of Python's behaviour and conclude from that that Python is call-by-reference. Then there's these: "I was under the assumption that everything in python was a reference. So if I code this: ... I though the contents of lst would be modified." http://mail.python.org/pipermail/python-list/2006-January/360222.html "Python passes references to objects by value (like Java), and everything in Python is an object. This sounds simple, but then you will notice that some data types seem to exhibit pass-by-value characteristics, while others seem to act like pass-by-reference... what's the deal?" http://www.goldb.org/goldblog/CommentView,guid,4eb92070-c279-44b3- ac2a-5d1c4f3e8115.aspx (The deal is, p-b-v and p-b-r are not the only two choices.) And here: "Python passes all arguments using 'pass by reference'." http://www.penzilla.net/tutorials/python/functions/ And from the one thread: "Python uses bog standard call-by-reference" -- Nick Maclaren, University of Cambridge Computing Service: http://mail.python.org/pipermail/python-list/2000-April/030077.html "I would describe Python parameter passing as call-by-value, with the wrinkle that the value being passed is always a reference to an object." -- Greg Ewing, Computer Science Dept, University of Canterbury (NZ) http://mail.python.org/pipermail/python-list/2000-April/030315.html -- Steven -- http://mail.python.org/mailman/listinfo/python-list
