Modifying Class Object

[Terry Reedy]

On 2/11/2010 1:37 AM, Alf P. Steinbach wrote:

> Consider just the
> assert( t is not s )
> t = s
>
> Does this change anything at all in the computer's memory?

By 'computer', do you mean 'anything that computes' (including humans) 
or specifically 'electronic computer'?

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

Agreed, in whatever 'memory' the 'computer' is using.

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

I prefer to use the word 'associated': namespaces are a many-to-one 
association between names and objects.

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

T and s are both associated with the same object.

> That explanation in terms of "refers" is necessary.

I disagree

> No beginner knows what it means that a name is "bound" to something means, until it's been
> explained.

I agree, which is why I am trying to avoid 'bound', etc, in favor of 
'associated'. One problem of 'bind' is that it sometimes raises the 
question of which is bound to which. 'Associated' avoids that.

> The explanation is necessarily in terms of "refers to".

I have given an alternative, even if you still prefer yours.

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

I presume you agree that the name 'Alf P. Steinbach' refers to you. Do 
you then consider it to be a 'reference' to you? In either case, the 
Python definition uses 'refers to' in the same way that names refer to 
people, and did even before names were used in electro-mechanical 
computer programming.

 >Steven D'Aprano:
>> 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.

About 13 years ago, I noticed that electronically executable Python was 
very similar to some of the designed-for-human-reading algoritm 
languages (pseudocode) that were not. I then coined the oxymoron 
'executable pseudocode' for Python. I see the difference between the 
descriptions as reflecting the difference between Python, the executable 
algorithm language and Python, the machine programming language.

 >> 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.

I think anyone writing books using Python should at least understand the 
abstract view even if he prefers to write from the more concrete view.

Terry Jan Reedy