Hello all, This is all good explanation, but could use a bit of tweaking. Where the pointer analogy with C breaks down is that C pointers require explicit dereferencing. In this regard, the Python model is actually closer to C ++ reference variables, which are automatically dereferenced. Of course it also differs from references in that in Python the referent for a variable can change (just reassign it). Still the intuition should be just about right for C++ programmers.
I myself like to think of Python variables as "sticky notes" that are attached to values so we can look them up later. This thinking is a clean break from pointers or references. Variables are not locations to have values placed in them. They are names that can be attached to objects. The discussion of NULL below is not quite accurate. NULL is a value stored into a variable in C/C++, that is, it is a value to say the the pointer/reference does not point to anything. However, None in Python is actually just the name (i.e. a variable) denoting a particular object. When you assign None, you are just setting the variable to point to that object. In C++, if you created a None object, then you could certainly pass any variable containing None as the actual argument for a reference parameter. In the final analysis Martelli is absolutely right. All parameters are passed by _value_ in Python. It's just that all variables are references to objects, so that means when you get a copy of the variable that copy is just another reference to the same object (i.e. you get a copy of the reference). Again, for C programmers, it is similar to getting a copy of a pointer. What I particularly like from a teaching standpoint is that parameter passing in Python works exactly like assignment. Just think: "assign the actual parameters of the caller to the formal parameters in the callee and execute the function body." There's nothing else to it. --John On Sun, 2008-05-04 at 15:57 -0500, Michael H. Goldwasser wrote: > Hi Dave, > > For students familiar with C, the most straightforward analogy is > that ALL of Python's names are akin to C's pointers. This is > certainly the closest match of the three C/C++ models (value, > pointer, reference). > > Even for new programmers with no previous knowledge, we make sure to > portray names distinctly as pointers to the underlying object in > memory, rather than to cloud the role of the name versus the value. > > Advantages of this analogy are the consistency of the following > semantics: > > * Assignment "a = b" creates an alias, whereby a and b both > reference the same underlying object. > > * Parameter passing is equivalent to passing a pointer in C. > With a signature, def foo(bar):, the calling syntax > foo(myList) simply assigns the formal parameter bar to point to > the same underlying object as the actual parameter myList. In > fact, it is exactly the semantics of the standard assignment > "bar = myList" other than the distinction in scope between the > local variable and the caller's. > > * None in Python is analogous to NULL in C. > > As an aside, this is why I prefer to compare Python's model to > pointers in C/C++ rather than to references. When passing a > reference variable in C++, the formal parameter must be bound to > an actual object (you cannot pass a null reference). > > > Having used this analogy, there are a few things that should be > explained to those used to C. > > * You cannot directly manipulate memory addresses in Python as you > can in C. Internally, Python's interpretter maintains those > memory address. In fact, the value of id(x) is typically the > underlying memory address. But you cannot use that address to > access anything, nor can you do pointer arithmetic as in C. > > * There is an independent issue in that Python's primitive types > (int/str/tuple) are immutable. So when passing an integer as a > parameter, the mechanism is still pass-by-reference however this > does not give the callee any power to alter the original value. > I think this is why there are some who errantly characterize > Python as using pass-by-value . > > As a final aside, if student have any familiarity with Java, the > Python model is quite simple to explain. It is precisely that which > Java uses for all object types. > > With regard, > Michael > > > On Sunday May 4, 2008, David MacQuigg wrote: > > > This was the question from a student at my recent lecture to a class of > > engineering students studying C. My answer was brief: It doesn't - > > arguments are passed by value. Then I thought, this is really misleading > > for students of C, where pass-by-value means making a copy of the passed > > object. So I'm looking for a simple answer that is complete, but doesn't > > baffle freshmen whose only experience so far is an introductory course in > > C. > > > > How about this: > > > > ''' > > Python doesn't use pointers, but they really aren't needed in Python, > > because the way objects in memory are accessed is fundamentally different > > than C. Objects in Python are "bound" to variable names. These names are > > associated with pointers, but that is at a lower level not seen by the > > Python programmer. If you need to get down to that level, you should be > > using C, not Python. > > ~ ''' > > > > That's a little better than my first answer, but I could elaborate with > > further discussion about argument passing. > > > > ''' > > You know that in C there are two ways to pass a value to a function: > > call-by-value and call-by-reference. Call-by-value puts a copy of the > > value in the function's memory area. Call-by-reference passes to the > > function a pointer to the original value in the caller's memory. In > > Python, passing a value to a function is done by "binding" the name of the > > parameter in the function to the value in the caller's memory. This is > > like call-by-reference in C, but the Python programmer never sees the > > pointer. > > ~ ''' > > > > Note that Martelli says "all argument passing in Python is by value" > > (Python in a Nutshell, p.74), but I think this may be an error. > > > > I would be interested in seeing how others would handle this question. > > > > -- Dave > > > > P.S. The lecture went very well. The students were enthusiastic, and > > the Mandelbrot images were stunning! > > http://ece.arizona.edu/~edatools/ece175/Lecture The purpose of the lecture > > was to introduce students to higher-level programming, and show how C can > > still play a role when performance is critical. I'm hoping to expand this > > to a 3-week sequence of lectures. > > +----------------------------------------------- > | Michael Goldwasser > | Associate Professor > | Dept. Mathematics and Computer Science > | Saint Louis University > | 220 North Grand Blvd. > | St. Louis, MO 63103-2007 > > _______________________________________________ > Edu-sig mailing list > [email protected] > http://mail.python.org/mailman/listinfo/edu-sig > -- John M. Zelle, Ph.D. Wartburg College Professor of Computer Science Waverly, IA [EMAIL PROTECTED] (319) 352-8360 _______________________________________________ Edu-sig mailing list [email protected] http://mail.python.org/mailman/listinfo/edu-sig
