[Edu-sig] How does Python do Pointers?

Wed May 7 00:43:20 CEST 2008

Although I like the post-its analogy, good advertising for 3M, there's
an implied thesis about proximity (post-its "stick to" something)
whereas I'd like students to thing of objects as potentially very
heavy and far removed, connected more by wire or rope.

This matches very early conversations about edu-sig about Python's
bias against copying, i.e. you need to import from a separate module,
and even then, deepcopy is something special, considered usually
unneeded, i.e. Python the design, like any design, encourages and
discourages ways of thinking, and Guido is pretty clear about what
he's trying to cut down on (copying).

Because once your names really do point to objects, potentially
associated with huge amounts of data (as objects may be), then you
really *don't* want some x = y assignment to involve truly copying
anything, as that implies potentially major consequences in memory
sometimes.

So I'd say Python's emphasis on names sharing an object, is consistent
with Python's strong bias against copying.

I like the point made earlier that parameter passing at the function
gateway is all about assignment, and assignment is all about cloning a
pointer or reference, for use within the local scope, and these names
are by definition something tiny, whereas the objects themselves --
who knows how big these might be.

Kirby

2008/5/6 David MacQuigg <macquigg at ece.arizona.edu>:
> Fredrik Lundh has yet another point-of-view:
>
>  http://effbot.org/zone/call-by-object.htm
>  '''
>  Python's model is neither "call by value" nor "call by reference" (because any attempt to use those terms for Python requires you to use non-standard definitions of the words "value" and "reference"). The most accurate description is CLU's "call by object" or "call by sharing". Or, if you prefer, "call by object reference".
>  ...
>  IT IS NOT CALL BY VALUE because mutations of arguments performed by the called routine will be visible to the caller. And IT IS NOT CALL BY REFERENCE because access is not given to the variables of the caller, but merely to certain objects.
>  ~ '''
>
>  I guess what we need is a taxonomy of definitions: strict/loose, mechanism/result.  I prefer a loose definition based on mechanism, like Kernighan and Ritchie.  So for me it's call-by-reference, but I don't mind softening that a bit with "like call-by-reference".  For Lundh, its strict definitions only, and Python fits neither.
>
>  Anyway, it looks like the waters are so muddy now, that the simple concepts of the early days have lost their value.  None of this should pollute our classrooms.  Let's all stick with sticky notes. :>)
>
>  -- Dave
>
>
>
>
>  At 11:47 AM 5/6/2008 -0700, David MacQuigg wrote:
>
>  >John,
>  >
>  >This is the best explanation I've heard so far for why Python is "call by value", but it still leaves me dissatisfied that what I thought was simple (call-by-value) is really complicated and not very useful to me, and what is truly simple (passing a copy of the object) is a useful concept with no name.  I also wonder if I'm completely misunderstanding the Wikipedia article (and other texts like K&R - Kernighan and Ritchie p. 27), or if there aren't two schools of thought with conflicting terminology.
>  >
>  >As usual, the confusion in the discussion arises when there are differing underlying assumptions, unstated and unrecognized.  I was assuming the word "value" referred to a part of the object in the simple scheme - variable:(name, pointer) --> object:(type, value, address).  I see now that "value" can mean the pointer, and that making a copy of the pointer can be passing a "value".  Perhaps we should refer to the object as having (type, data, address) and save the word "value" for the meaning you assume.
>  >
>  >At 10:55 AM 5/6/2008 -0500, John Zelle wrote:
>  >
>  >>David,
>  >>
>  >>Actually, I don't think there is that much confusion among the folks who
>  >>understand/design/study programming languages. Python uses call by
>  >>value, period, as that term is technically used. But your note below
>  >>shows the continued confusion (among programmers) about what parameter
>  >>passing terminology. In classifying calling mechanisms, the question is
>  >>what happens with a variable being passed and the value it (contains in
>  >>the traditional usage of those words); it has nothing to do with
>  >>objects. When modeling Python semantics, a variable actually holds a
>  >>reference (pointer, address) of an object. When the variable is passed
>  >>as a parameter, its value (the reference/pointer) is copied into the
>  >>formal parameter variable. That's it. It's call by value.
>  >
>  >Understood now.  The value is the pointer, not the data.
>  >
>  >>The confusion and fuzzy thinking comes because the automatic
>  >>dereferencing of Python variables when they are used in expressions
>  >>leads people to think about objects being "stored in" variables. Then
>  >>they talk about whether objects being copied or not copied in function
>  >>call parameters. But an object is _never_ stored into a Python
>  >>variable.
>  >
>  >Never any misunderstanding for me.
>  >
>  >>To see the difference between passing a mutable object in Python vs. a
>  >>reference parameter in other languages, you just have to ask if you can
>  >>change the value of the calling code's variable by assigning a value to
>  >>the corresponding formal parameter in a function.
>  >
>  >With your definition of "value", it never changes.  The assignment creates a new local variable in the function's namespace.
>  >
>  >> In C++ or Pascal,
>  >>setting the value of a reference parameter actually changes the contents
>  >>of the variable in the calling program.
>  >
>  >Understood, but now we are using the previous definition of "value".  If we use the definition above, changing the "value" just points the parameter name in the function to some other address.
>  >
>  >In C if I have a parameter (int *x) then x is the address of an int.  The actual value passed is an address, and an assignment statement in the function can change the data at that address.  But it is still "call-by-value" according to K&R, since the value in this case is an explicit address, with 32 bits of data looking just like an unsigned integer.
>  >
>  >>def func(formal_param):
>  >>     # change the value of formal_param to be a reference to foo_object
>  >>     formal_param = foo_object
>  >>
>  >>x = bar_object
>  >>func(x)
>  >># for pass by reference, x would now contain a foo_object
>  >># In Python (pass by value) x is still bar_object.
>  >>
>  >>In Python, you cannot change the actual parameter variable (x above). No
>  >>matter what you do in the function, the actual parameter still contains
>  >>the same thing, a reference to the same object it was always pointing to
>  >>at the time of call. That's because the function operates on it own copy
>  >>of that reference, not the _actual_variable_ of the caller.
>  >>
>  >>Summary: Python's parameter passing is just call by value. But Python
>  >>variable values are always references and Python semantics dictates that
>  >>those values are dereferenced when variables are used in expressions.
>  >>That leads some programmers to (imprecisely) talk about parameter
>  >>passing in terms of variables having objects as values. I often do this
>  >>loosely myself, because it's easy to think of a Python name as a
>  >>variable that stores and object.
>  >
>  >When I hear "variable x has value y" I think of x pointing to object y, not storing y, not even loosely.  My confusion is not due to misunderstanding what Python actually does.
>  >
>  >It seems like there might be a simple alternative to the traditional definition of "call-by-value" in terms of result rather than mechanism.  The traditional definition (K&R) is simple if you think of mechanism.  The new definition is simple if you think of result (argument in calling program not changeable by the called function).
>  >
>  >Should we add a note to that Wikipedia page?
>  >
>  >-- Dave
>  >
>  >
>  >>On Tue, 2008-05-06 at 07:45 -0700, David MacQuigg wrote:
>  >>> I agree, there is no reason to dig into call-by-??? terminology with new "untainted" programmers.  The sticky-note analogy is all we need for these students.  The figures in Michael's book are excellent.
>  >>>
>  >>> However, having been tainted by C, I am finding the discussion interesting.  I just don't understand why there is so much confusion with these call-by terms.  Does the function get a copy of the object or a reference to the original object?  It's got to be one or the other.
>  >>>
>  >>> At 10:11 PM 5/5/2008 -0500, Michael H.Goldwasser wrote:
>  >>>
>  >>> >  Python's model is quite clean, it just doesn't match up perfectly
>  >>> >  with the standard call-by-??? terminology.
>  >>>
>  >>> In call-by-reference evaluation, a function receives an implicit reference to the argument, rather than a copy of its value.
>  >>> -- http://en.wikipedia.org/wiki/Call_by_value
>  >>>
>  >>> By this definition, Python's model is call-by-reference, even though the reference (pointer) is not seen by the user.  C's model is call-by-value, even though that value can be an explicitly-evaluated address (pointer).
>  >>>
>  >>> -- Dave
>  >>>
>  >>>
>  >>> _______________________________________________
>  >>> Edu-sig mailing list
>  >>> Edu-sig at python.org
>  >>> http://mail.python.org/mailman/listinfo/edu-sig
>  >>>
>  >
>  >
>  >_______________________________________________
>  >Edu-sig mailing list
>  >Edu-sig at python.org
>  >http://mail.python.org/mailman/listinfo/edu-sig
>
>
>
> _______________________________________________
>  Edu-sig mailing list
>  Edu-sig at python.org
>  http://mail.python.org/mailman/listinfo/edu-sig
>
>