Modifying Class Object

[Alf P. Steinbach]

* Steven D'Aprano:
> On Tue, 09 Feb 2010 05:01:16 +0100, Alf P. Steinbach wrote:
> 
>> * Stephen Hansen -> Alf P. Steinbach:
>>> [snip]
>>> 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!
>> Then, when the imprecision makes people misunderstand, one should not
>> say that.
>>
>> One should then be more precise.
>>
>> One should say /what/ is passed by value.
> 
> I don't see how that matters. Python's behaviour is EXACTLY the same, no 
> matter what you pass to the function.
> 
> You don't pass pointers in Python, because you, the Python author, have 
> no way of specifying a pointer in Python code. It is *always* an object 
> that you pass, by giving a literal, the name an object is bound to, or 
> some other expression that returns an object:
> 
> function( my_object )
> function( 12345 )
> function( ham(3) + spam(5) )

Every name and literal above (and in Python generally) stands for a copyable 
reference to an object, not for the object itself. You can copy the reference:

   a = [123]
   b = a
   assert( a is b )    # Doesn't matter if mutable or immutable or what.

A copyable reference is a pointer. That is, a "pointer", in e.g. the Java sense, 
  and in the general language independent sense, means a copyable reference  -- 
  as illustrated e.g. in the Stanford computer science 101 course page I 
referred you to earlier, with C versus Java pointers illustrated in the concrete.

Hence, since every name and literal above stands for a copyable reference, and 
since a copyable reference is a pointer, every name and literal above stands for 
a pointer  --  that's /all/ that you handle directly in Python, namely pointers.

But if that terminology sounds bad or has too strong C-vibes or Java-vibes or 
whatever, then we just need some other term for a Python "copyable reference".


> If you're talking to the person who writes Python code, then you should 
> discuss the sorts of things that exist in Python: objects and names and 
> expressions, but no pointers.

Well, given this terminology debate we may need some other term.

But IMHO the horse drawing the wagon needs to be mentioned to the potential 
wagon driver, whatever that horse is called  --  fourfooter, drawing-animal...

Anything else seems just senseless, meaningless abstraction, replacing one 
simple single concept with a load of connections and special case rules.


> If you're talking about the Python virtual machine, instead of the high-
> level Python code, then you should say so -- but there are still no 
> pointers in the VM. Look at the output of dis.dis and you will see 
> objects pushed onto a stack, but no pointers.

I don't think you will see any Python objects pushed on the stack. But you will 
see copyable object references pushed on the stack. That is, you will see 
pointers pushed on the stack.


> It's not until you get past the level of Python code, past the virtual 
> machine, and into the implementation of the virtual machine, that you 
> will finally find pointers.

There too.


> But why stop there? If somebody asks you a question about Python, and you 
> choose to ignore them and answer a different question about one 
> particular implementation's internals instead, I don't see why you stop 
> there. Why not go down another layer and talk about copying bytes, or two 
> layers and answer that Python does call-by-bit-flipping, or a layer below 
> that and say it's all done by varying potential differences?

I think a good professional programmer knows about all these levels.

Unfortunately, at least about 10 years ago students fresh out of college in 
Norway did not know about "internal" things such as call stacks, which led them 
to adopt many Unholy Programming Practices and to be Extremely Baffled by things 
such as stack traces.


> You shouldn't expect your listener to understand machine code to 
> understand Python's high-level behaviour, nor should you expect them to 
> be C coders. You don't need to understand pointers to understand a 
> language that doesn't support them.

 From the above comments it seems you're thinking about C pointers. To prevent 
that misconception I've defined the term "pointer" in every or most every 
posting I've made in this thread, including this posting. I've also posted a 
link to a Stanford University page with a simple-words explanation (they even 
have an animated Bunny video, although I've not looked at it); it's CS 101.

You don't have anything /but/ pointers in Python.

So pointers are key  --  by whatever name.


[snip]
> Java programmers suffer for a bad mental model just as much as Python 
> programmers.

Yes. :-)


> All this is because of two conceptual mistakes: (1) the Java community 
> has conflated the internals of what happens in the implementation of the 
> Java VM with high-level Java code; and (2) a refusal to accept that there 
> are calling strategies other than pass-by-value and pass-by-reference.

I'm not entirely sure about causes, but there is a tendency in general for 
humans to go from one extreme to another that they regard as "opposite". Using 
the term "call by value" for the Java (and Python) parameter passing is just 
Wrong(TM), at least without a clear understanding of what can be passed. Using 
"call by value" in a description of that model, mentioning very clearly what's 
passed, is on the other hand very practical: it's short, succinct & correct.


Cheers & hth.,

- Alf