Modifying Class Object

[Stephen Hansen]

On Mon, Feb 8, 2010 at 4:44 PM, Alf P. Steinbach <alfps at start.no> wrote:

> No, one only needs an understanding of "pointer".
>
> "Pointer" is a mostly language independent concept.
>
> The reference to the Java language spec, where that term is used for this,
> was just an unsuccessful attempt to keep out word-play arguments based on
> the incompatibility of some incompatible meaning of "pointer"...
>

The fact is, "pointer" is not really a language independent concept. Just
because a concept is used in multiple languages doesn't make it a general
purpose term that has a clear meaning that's defined in a well-understood
way. The last time I paid attention to one of your semantic arguments was
when you were talking about "routine", where that -was- a language
independent concept, but as wholly inappropriate to use in context of Python
as pass-by-value (especially due to ambiguity). You seem to have an idea of
a word in your head and a meaning and context, and are ignoring the fact
that there's a huge body of knowledge that places another context or meaning
on that word or phrase. Thus, the usage of that phrase actually -confuses-
and does not -clarify-.

The terms "call by reference" and "call by value" have *meaning* beyond the
purely abstract: they have meaning to semantics that people expect when you
use them, meaning to how the language works, and those meanings do *not*
apply to Python.

Python doesn't have pointers. That you can do id() and see something like a
memory address is a CPython implementation detail which is not guaranteed
and the fact that Python is implemented -in- a language which -does- have
pointers, and that implementation uses pointers beneath the Python level.
But the Python language (and CPython implementation) does -not- provide
pointers to us. We do not use pointers in any Python code we do.

To say, "pass by value" implies things to people. It describes a sort of
world where I'm a function about to do some work, and on my desk I have a
series of boxes with names on it. It describes an environment where someone
comes over and drops something into each of my boxes. The contents of these
boxes are mine alone!

To say, "pass by reference" implies other things to people. It describes a
sort of world where my desk doesn't have any boxes, really. It's got some
places for boxes, but when someone gives me something? They give me their
boxes too. The actual -stuff- in them I can swap between the two boxes if I
want, and when I give those boxes back to the one who called me? They'll be
swapped. That's a sort of defining characteristic of pass-by-reference
environments.

_Neither_ of these are accurate descriptions of Python's universe. You can
say, "its pass by value, just be specific that the value is..." but at that
point the statement is meaningless. You've taken a relatively
well-understood statement with certain meaning and a semantic weight behind
what it means, and just totally made it into something else entirely. By
changing the entire meaning of "value", from the value of the variable which
is copied, to the value of the memory address, you've changed -everything-
that 'pass by value' means. So you should use a different word.

Like, "objects" (or "sharing" is also used.)

Python has names, and objects. The guy over there has things on his desk,
with a label attached to it that has a name. He tosses it over to me, and I
get the same object he did-- no boxes. I put my own label on it, even though
he keeps hold of his label. I fiddle with it, and might toss it back. Or
might not, maybe I'll toss something else back. Either way, he still has it.

In Python, we get objects. Real objects. The original one. Its not a
pointer, its an object, that happens to have a label attached to it. It
doesn't have any idea what that label is, and it can't even find out. Its
not in any boxes owned by any functions, its just floating out there with
everything else, with lots of labels tied to it. Its just that when the last
one is cut, nothing else is holding it up, and it falls to the ground and
gets swept away.

That python is pass-by-objects is -really- important for people to
understand to really "get" python, and using other terms is /bad/ because it
makes them think of the semantics those terms imply. Because if you don't
-remember- and just instinctively -know- that Python is "pass-by-objects",
you'll forget the difference between passing an immutable and a mutable
object into a function, and be surprised by the result.

>>> import copy
>>> def doit(a):
...     a += a
...     return a
...
>>> test1 = 1
>>> test2 = doit(test1)
>>> test1
1
>>> test2
2
>>> test3 = [1]
>>> test4 = doit(test3)
>>> test3
[1, 1]
>>> test4
[1, 1]

I know you already know this, but the point is: you're -hurting- other
peoples understanding by using terms like this that don't apply to Python's
specific nature.

In Python, every function gets the original objects that you pass into it.
Some are immutable, some are mutable. With immutable ones, it might very
well seem like its pass-by-value and behaves like pass-by-value semantics,
but when you get mutable objects, that changes /quickly/. Changing "value"
to mean, "the memory address where the object is stored" just obfuscates the
entire point and doesn't actually explain what people need to understand in
this question.

--S
P.S. I couldn't resist. :(
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-list/attachments/20100208/85bf27f8/attachment-0001.html>