Variables with cross-module usage

[Terry Reedy]

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 
slower execution.

Terry Jan Reedy