Variables with cross-module usage

Lie Ryan lie.1296 at gmail.com
Tue Dec 1 00:01:21 EST 2009


On 12/1/2009 7:51 AM, Terry Reedy wrote:
>> In everyday life and natural languages, a single name can be used to
>> refer to multiple objects just by context without referring any
>> namespace.
>
> Namespace are contexts. They were (re)invented in programming just to
> make it easier to have single name could refer to different objects --
> in different contexts. Names bound within a function are interpreted as
> being within the default local context without explicitly referring to
> it. Indeed, one cannot explicitly refer to the local namespace of
> functions, only to a dict copy thereof.

Let's stop with the silly analogies.

>  > Let's not start making analogism between nature and silicon.
>
> There are several things wrong with this.
>
> You meant 'analogies'.

No, I meant "analogism". My spellchecker lined that red, but I know what 
I meant. Let me define this word, which apparently is not (at least yet) 
in the dictionary:
- analogism: the way of thinking that analogy must be perfectly similar 
to the "real thing" in every single way, to the point of making grand 
and complex story that is even more complicated than the "real thing" 
itself.

> I did not go into that counterclaim, but indeed, many people who program
> in C, for instance, use C names as if they were object names instead of
> location names (or location,increment tuple names). Sometimes they even
> forget that they are really just location names. One too-common result
> of that confusion has been buffer overruns and virus programs that
> exploit them. These are impossible in Python.

"address names" and "object names", those are a good definition; stop at 
that. Any more layers of analogies, with boxes, with strings, with how 
human uses "name" in social life, or with how snakes align themselves 
with stars are much less useful than just learning how the "name" itself 
behave.

Let's stop teaching with excessive analogies, they just provide layers 
and layers of thinking that would confuse people when the analogy 
doesn't match the "real thing". Just learn how they behave, directly.

Analogy are fine to describe when first explaining how roughly something 
works, but don't expect things to be the same down to the details; and 
worse, don't make more analogies to cover up for the points the previous 
analogy doesn't cover.

Just stop the "analogism" [1]!

[1] there I used the word again.



More information about the Python-list mailing list