Modifying Class Object

[Alf P. Steinbach]

* Steven D'Aprano:
> On Wed, 10 Feb 2010 23:56:36 +0100, Alf P. Steinbach wrote:
> 
>> * Steven D'Aprano:
>>> On Wed, 10 Feb 2010 21:02:14 +0100, Alf P. Steinbach wrote:
>>>
>>>> "pointer" refers to a copyable reference value as seen from the Python
>>>> level, in the same way as "pointer" is used by e.g. the Java language
>>>> spec.
>>> Python doesn't have "copyable reference values" in the Python level. It
>>> has objects.
>> Given
>>
>>    s = [1]
>>    t = s         # Copies reference.
>>    t[0] = 2      # Changes referenced object via copied reference.
>>    print( s )    # Checks the object via the original reference.
>>
>> your argument that the copied reference does not exist, is just silly.
>>
>> And you know it.
> 
> You keep making a habit of pretending that you know what other people are 
> thinking,

No, that is untrue, I do neither know nor pretend to know what other people are 
thinking.

But I do know that you know some elementary things, such as understanding what 
the code above does.

I do not by that mean that you don't also understand far more advanced things 
:-), just that I'm fairly ~100% sure that you do understand the code above.


> accusing them of lying for having an opinion that differs from 
> yours,

That is untrue.


[snip]
> I don't "know" it is a silly argument, because I don't accept your 
> givens. Specifically:
> 
> s = [1]
> t = s         # Binds the name t to the object bound to the name s.
> t[0] = 2      # Changes the object bound to the name t
> print(s)      # Checks the object via the original name.
> 
> Notice that your version describes what happens according to some 
> implementation, below the level of the Python virtual machine.

Consider just the

   assert( t is not s )

   t = s

Does this change anything at all in the computer's memory?

If it doesn't, then it has no effect whatsoever.

But since it does have an effect, a memory change has been effected.

You describe that memory change as that t has been "bound" to the same object as s.

By which you mean that henceforth, until the next assignment to t, t *refers* to 
the same object as s.

That explanation in terms of "refers" is necessary. No beginner knows what it 
means that a name is "bound" to something means, until it's been explained. The 
explanation is necessarily in terms of "refers to".

When something A refers to something B, then by definition A is a *reference* to B.

Anyway, you have changed which object t refers to, by changing memory contents 
so that t now refers to the same object as s.

Effectively, by making t refer to the same object as s, by all measures of 
reference equality (which is just, do they refer to same object?) you have 
*copied* the s reference to t.

For if you haven't, then t necessarily refers to something else.

So the memory change, whatever it was, involved an effective copying of a 
reference, in memory.

And that copying of a reference, in memory, implies a copyable reference.

Going the other way, copying of references very directly implies binding. No 
need for the long logic chain above. So copying of references is in my view much 
more powerful as a model of what goes on, yielding immediate conclusions, 
avoiding special case rules, and being very suitable for visualization.

Not the least, it's more powerful because in order to explain "bind" you need 
"refer" and "reference", so the "bind" view involves more, violating Occam's.

But given the explanation in terms of "refer" and "reference" you do not need 
"bind", so it's less, it's simpler  --  and it's easier to visualize.


   ---


Anyway, there is more practical way to look at it.

Say that you're going to implement a linked list.

The functionality required for that is exactly that of general pointers. But a 
linked list can be implemented in Python, using names (attributes) as pointers. 
And since that works, without having to do anything extra in order to 
"implement" pointers in terms of names, but just using those names directly, 
those names necessarily have the functionality of general pointers.


> My version 
> describes what happens at the level of high-level Python code, which is 
> the defined semantics of the language. It makes no assumptions about the 
> implementation, completely unlike yours which is entirely implementation-
> specific. My description is equally valid whether Python is being 
> executed by the CPython virtual machine on an Intel-compatible processor, 
> or hand-simulated with pencil and paper, or something completely 
> different. Yours is not.
> 
> I describe the high-level language, you describe one implementation. 
> Neither view is *wrong*, per se, but one describes the semantics of the 
> language while the other describes the implementation.
> 
> The first paragraph of the Python docs about the execution model says:
> 
> "NAMES REFER TO OBJECTS [emphasis added]. Names are introduced by name 
> binding operations. Each occurrence of a name in the program text refers 
> to the binding of that name established in the innermost function block 
> containing the use."
> 
> http://docs.python.org/reference/executionmodel.html
> 
> Apart from the use of the generic English term "refers to" (and similar), 
> you will find *nothing* about pointers in this. That's because pointers 
> are not a part of the high-level behaviour of Python.

Well, apart from... As you say.


> See also:
> 
> http://docs.python.org/reference/simple_stmts.html#assignment-statements
> 
> where you will also not find the word "pointer" used to describe any high-
> level Python feature, or used in relation to assignment.

Yes, that's right.

It does not mean that such a description is invalid.

It only means that common sense needs to be applied, and that the urge to 
misinterpret needs to be suppressed. I don't think those are problems for 
novices. But still a better term than "pointer" would be nice, and I guess 
"reference" is it, as suggested by the course material I linked to.


Cheers & hth.,

- Alf