Modifying Class Object
tjreedy at udel.edu
Thu Feb 11 23:11:17 CET 2010
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.
> No beginner knows what it means that a name is "bound" to something means, until it's been
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
>> 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
More information about the Python-list