Is 'everything' a refrence or isn't it?

[Mike Meyer]

Steven D'Aprano <steve at REMOVEMEcyber.com.au> writes:
> Mike Meyer wrote:
>> Peter Hansen <peter at engcorp.com> writes:
>>>Steven D'Aprano wrote:
>>>>Python does not have references or pointers, except internally where
>>>>Python coders can not get to them. It has names and objects. Keep thinking
>>>>about "call by reference" and you just confuse yourself and others. Think
>>>>about names and objects and it is simple and straight-forward.
>>>I won't argue the point, but I would point out that the term "name" is
>>>insufficient for whatever it is that is stored inside a list.
>> Correct. What's stored in a list is a reference.
> Nonsense. What is stored in the list is an object. Python doesn't have
> pointers. You are confusing the underlying C implementation, which
> implements lists as an array of pointers, with the high-level Python
> code, which doesn't even know what a pointer is. It only has objects.

I didn't say a single word about C, or pointers, or anything else to
do with the implementation.

> Since we are discussing the perspective from a Python
> programmer's point of view, it is irrelevant what the C implementation
> does. If lists held references, you could do this:
>
> x = 5
> L = [1, 2, x]
> # the third item points to the same memory location
> # as x; changing it will also change x
> L[2] = 7
> assert x == 7
>
> which is the behaviour that "call by reference" implies. But it
> doesn't work that way in high-level Python code.

Now you're talking nonsense. Call by reference is about *parameter
passing*, not about the behavior of assignment statements or
lists. How the above code behaves has *nothing* to do with how Python
passes parameters.

> The *reason* it doesn't work is that the object 5 is immutable.

The immutability of 5 has *nothing* to do with it. If you replace 5
and 7 with mutable objects, you get the exact same behavior:

x = [5]
L = [1, 2, x]
L[2] = [7]
assert x == set([7])

You seem to be suffering from the newbie confusion of thinking that a
Python assignment statement writes a value into the lvalue. It doesn't
- it makes the lvalue a reference to the object the right side
evaluates to ("binds a name to a value", except sometimes the lvalue
isn't a name). I'm pretty sure you know the difference.

The same thing applies to CBR/CBV. The immutability of the objects
being passed ain't got nothing to do with it. It's the fact that
assignment statements bind values instead of write them into a
variable that makes Python's CBR behavior sometimes act like CBV.

> If you only ever passed mutable objects around, you would think
> Python was call by reference.

True. But you'd still run into things that you can do with CBR in
other languages that you can't do in Python. That's not because Python
isn't CBR, it's because those other languages have things that Python
doens't have.

> And if you only ever passed immutable objects around, you would
> think Python was call by value.

You might. Then again, you might also understand the concepts well
enough to realize that there isn't any difference between CBR and CBV
when you're passing immutable objects.

> But since Python has both sorts of objects, it displays both sorts
> of behaviour.

Again, the mutability (or lack thereof) of the objects being passed
doesn't have anything to do with it. The things you can do in other
languages using CBR that you can't do in Python - like changing the
binding of a name in the callers namespace - you can't do whether the
name is bound to a mutable object or an immutable object. That Python
looks like CBV when you pass immutable objects is because CBR looks
like CBV when you pass immutable objects.

    <mike
-- 
Mike Meyer <mwm at mired.org>			http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.