Alf P. Steinbach
2/11/2010 10:27:00 PM
* 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