Replacement for keyword 'global' good idea? (e.g. 'modulescope' or 'module' better?)

[Bengt Richter]

On Sat, 06 Aug 2005 20:56:13 GMT, Dennis Lee Bieber <wlfraed at ix.netcom.com> wrote:

>On Sat, 06 Aug 2005 21:16:13 +0200, Paolino <paolo_veronelli at tiscali.it>
>declaimed the following in comp.lang.python:
>
>
>> The point is not to understand obvious technical things, but having a 
>> coherent programming framework.If I can modify an out of scope object 
>
>	Seems coherent to me: 
>
>a)	names /BIND/ locally unless declared global (at which point they
>bind within the file)
>
>b)	name /lookup/ is local first, then global
>
>c)	conflict occurs when a name lookup potentially could find a
>global [clause b: name not found in local space, found in global], but
>later in the same function that same name is bound locally [clause a: no
>global declaration was seen so binding is to a local]. However, the
>static language parse will have flagged the name as reserved for a
>local, and then complains because one is attempting to use a local
>before it has been bound to a value.
>
>	If you aren't changing the binding of the name, you don't need
>to worry about "global"
>
>	And, in Python, this concept of BINDING is a core language
>feature -- it is NOT something compatible to other languages, and
>removing it will mean creating a new language that is NOT Python.
>
>	In other languages, a "name" is a synonym for a memory address
>(call it a box), and it will always be the same box. Assignment copies
>box contents from source to destination box.
>
>	In Python, a "name" is a movable label that is stuck to a box,
>and the name can be moved to other boxes. "Assignment" in Python moves
>the label from the "destination" (the old box) TO the "source" box --
>the source box now has multiple labels (names) bound to it. Both names
>refer to the same box.
>
>	var[i]	is a two step process: first find the box with the label
>"var", THEN open the box and find the i'th item /in/ the box... You can
>change the item /in/ the box without changing the label on the box.
>
I find the above label/box metaphor a bit misleading, because the "box"
surfaces where "labels" may be stuck are name spaces, and IMO are more like
cork bulletin boards than the containers suggested by "box" (although
admittedly a bulletin board could be viewed as a kind of container for labels ;-)

I prefer the name-tags-with-strings metaphor, where name tags may be
pinned on any namespace/bulletin board and the strings from tags on
many different bulletin boards may be tied to (bound) the same object.

But to carry this a little further, name tags aren't really the only
things that have strings that lead to objects. Name tags's strings
are accessed via name space objects' lookup mechanisms, which we program
with various name lookup syntax, but other objects can also have strings
leading to objects, e.g. lists, where you retrieve a string originating
from the nth string-tying-point instead of finding a string-tying-point by name
amongst a bunch of labels pinned to a bulletin board.

IOW, "...open the box and find the i'th item /in/ the box..." is not really
finding the i'th item _itself_ "/in/" the box. It is finding one end of a string
tied to some point /in/ the box, but the actual item/object is at the other end
of the string, not /in/ the box, and many other strings may potentially also
be leading to the same object, whether originating from anonymous structural
binding points in other objects, or named binding points in name-tag-containing
objects/namespaces.

Regards,
Bengt Richter