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
--
http://mail.python.org/mailman/listinfo/python-list
