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