* 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'?
In this context I mean the virtual machine that a Python language assumes.
Doesn't matter if it's electronic or a pen-and-pencil simulation.
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.
"Associated" is just less precise than "refers".
"Associated" is two-way.
Anyway it's just a term, and if you define it to mean a one-way reference, then
nothing substantial is changed except more room for misunderstanding.
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?
Yes, and that's irrelevant, because you can't change a name. It's a slightly
different meaning. But a name edit field with my name in it most probably refers
to me.
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.
That's so subtle a distinction that it appears meaningless to me.
It says "refers to" but doesn't mean "refers to"?
>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.
It seems to me that you lack an understanding of the abstract here, going into
imagined and not concretely discussed differences between "refers to" and
"refers to".
Until or if (but I think it unlikely) you can explain clearly what that
difference between "refers to" and "refers to" is, it's just wordplay.
Cheers & hth.,
- Alf
--
http://mail.python.org/mailman/listinfo/python-list
