Variables with cross-module usage
tjreedy at udel.edu
Mon Nov 30 21:51:02 CET 2009
Lie Ryan wrote:
> On 11/30/2009 12:00 PM, Terry Reedy wrote:
>> Dennis Lee Bieber wrote:
>>> In these languages, the names always refer to the same location.
>>> Python confuses matters by having names that don't really refer to
>>> location, but are attached to the objects.
>> In everyday life and natural languages, names refer to people, other
>> objects, roles, and only occasionally to places that can be occupied. I
>> could claim that it is classical computer languages that confuse by
>> restricting names to locations in a linear sequence. You are just used
>> to the straightjacket ;-).
> In everyday life and natural languages, though an object may have many
> names/aliases; once objects are assigned a name, it is practically
> impossible to change the name to the object the name will be practically
> stuck to it forever.
When children play tag, the role of It is rebound to another child every
few seconds. When adults play conference, the role of Speaker or
Presenter is rebound to another person a few times per hour.
In Python, it easy, perhaps too easy, to rebind built-in names, but it
is usually a mistake. (Just yesterday there was a newbie post with that
mistake.) It is common for global names to be bound just once
(especially to functions and classes).
In both human life and programming performed by humans, the time scale
of name rebinding varies tremendously. Not surprising really.
> 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 not start making analogism between nature and silicon.
There are several things wrong with this.
You meant 'analogies'.
I will make them when I want to, which is when I think they are useful
in providing new viewpoints and insight. They are one way to break out
of straight-jacketed or boxed thinking. If you prefer your box, ignore me.
Silicon is a part of the natural world, and I was not making any such
analogy. Python is an information processing and algorithm language, not
a silicon programming language per se. And indeed, without a concept of
'address', it is not very suited to that.
I *was* making an analogy between how we communicate informally about
the natural and social worlds and how we communicate more formally about
the abstract information world. Is it really surprising that we use the
same psychological mechanisms? Silicon machine languages do not have
names. And names, as used by humans, *are* the subject of discussion here.
Dennis clained that Python is confusing because it is not restricted to
naming locations. I said I could claim instead that it is the
restriction is confusing.
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.
To me, the virtue of Python is that it allows one to think and write in
a relatively natural named-object model. Let the silicon-based
interpreter then translate that to a named-sequential-location model,
while avoiding the dangers thereof, even though it has the cost of
Terry Jan Reedy
More information about the Python-list