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

[seberino]

I've heard 2 people complain that word 'global' is confusing.

Perhaps 'modulescope' or 'module' would be better?

Am I the first peope to have thought of this and suggested it?

Is this a candidate for Python 3000 yet?

Chris

[Antoon Pardon]

Op 2005-08-06, Mike Meyer schreef <mw*@mired.org>:

"John Roth" <ne********@jhrothjr.com> writes:

<se******@spawar.navy.mil> wrote in message
news:11*********************@g47g2000cwa.googlegro ups.com...
A much better idea would be to fix the underlying
situation that makes the global statement necessary.

You can't "fix" this. This code (in some python-like langauge that
isn't python):

x = 23

def fun():
x = 25
# Rest of code

has two possible interpretations.

Either the occurrence of x in fun references the global, or it
references a local that shadows the global. There are reasons for
wanting both behaviors. So you have to have some way to distinguish
between the two, and you want it to happen per variable, not per
function. The method with the fewest keywords is to have one be the
default, and some keyword that triggers the other.

So the only way to remove the global statement would be to have some
way to mark the other interpretation, with say a "local"
decleration. I thik that would be much worse than "global". For one
thing, most variables would be local whether or not they are
declared. Second, having an indication that you need to check module
globals in the function is a better than not having that clue there.

I disagree here. The problem with "global", at least how it is
implemented in python, is that you only have access to module
scope and not to intermediate scopes.

I also think there is another possibility. Use a symbol to mark
the previous scope. e.g. x would be the variable in local scope.
@.x would be the variable one scope up. @.@.x would be the
variable two scopes up etc.

--
Antoon Pardon

[Antoon Pardon]

Op 2005-08-06, Peter Hansen schreef <pe***@engcorp.com>:

Paolino wrote:

se******@spawar.navy.mil wrote:
def enclosing():
var=[]
var[0]=2
def enclosed():
var[0]=4
which is like saying python is not working

It's ok to mark non locals,but why var=4 is not searched outside and
var[0]=4 yes?

Because "var=4" rebinds the name "var", while "var[0]=4" does not. It's
exactly the same issue with using "global", where you don't need it if
you aren't rebinding the name.

This doesn't answer the question at the appropiate level IMO.

Why has one made a difference in search policy for finding a
variable based on whether the variable is rebound or not
in the first place.

--
Antoon Pardon

[Peter Hansen]

Antoon Pardon wrote:

Why has one made a difference in search policy for finding a
variable based on whether the variable is rebound or not
in the first place.

Do you really not understand the reason, or do you simply disagree with
it? It's a choice with rational thought behind it. Whether it's the
best choice is a matter of opinion.

-Peter

[Bengt Richter]

On 5 Aug 2005 21:22:41 -0700, "se******@spawar.navy.mil" <se******@spawar.navy.mil> wrote:

I'm not saying 'modulescope' and 'module' are the only alternatives or
even
the best anyone can come up with.

'global' has the connotation of being visible *EVERYWHERE*
where in Python it is just visible in one module's space.
One way is to spell this with a dotted name (e.g., "shared" or "SHARED_GLOBALS")
and use a module dedicated for this purpose, e.g.,

import SHARED_GLOBALS
def foo():
SHARED_GLOBALS.x = 'shared x may be (re)bound from anywhere'

Can you think of a better alternative or do you believe
'global' is the best possible?

I don't think 'global' would be best if we were starting out with
the name spaces we have now, but as you know it effectively means 'modulescope'
and derives from a time where that was the only unqualified alternative
to local.

There's been a lot of discussion about this, periodically ;-)

Regards,
Bengt Richter

[Bengt Richter]

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

On Sat, 06 Aug 2005 21:16:13 +0200, Paolino <pa*************@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

[Ron Adam]

Antoon Pardon wrote:

I disagree here. The problem with "global", at least how it is
implemented in python, is that you only have access to module
scope and not to intermediate scopes.

I also think there is another possibility. Use a symbol to mark
the previous scope. e.g. x would be the variable in local scope.
@.x would be the variable one scope up. @.@.x would be the
variable two scopes up etc.

Looks like what you want is easier introspection and the ability to get
the parent scope from it in a simple way. Maybe something like a
builtin '__self__' name that contains the information, then a possible
short 'sugar' method to access it. '__self__.__parent__', would become
@ in your example and '__self__.__perent__.__self__.__parent__' could
become @.@.

Somthing other than '@' would be better I think. A bare leading '.' is
another possiblity. Then '..x' would be the x two scopes up.

This isn't the same as globals. Globals work the way they do because if
they weren't automatically visible to all objects in a module you
wouldn't be able to access any builtin functions or class's without
declaring them as global (or importing them) in every function or class
that uses them.

Cheers,
Ron

[Terry Reedy]

"Bengt Richter" <bo**@oz.net> wrote in message
news:43*****************@news.oz.net...

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.

The way I think of it is that Python's collective objects are like club
rosters: one person (object) can be on many rosters. A container would be
like a room, and a person could only be in one room at a time.

Terry J. Reedy

[Bengt Richter]

On Tue, 16 Aug 2005 19:24:04 -0400, "Terry Reedy" <tj*****@udel.edu> wrote:

"Bengt Richter" <bo**@oz.net> wrote in message
news:43*****************@news.oz.net...

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.

The way I think of it is that Python's collective objects are like club
rosters: one person (object) can be on many rosters. A container would be
like a room, and a person could only be in one room at a time.

Yes, the roster model works for me too, but I'm not sure I understand your
concept of "container/room" ;-) I.e., at the Python object level, object representations
themselves don't contain each other in the sense of the memory layout of nested
C structs, UIAM? Obviously there are C structs for basic object representation information
layout, but object-level parts are aggregated by reference via pointers rather than
by memory adjacency (again UIAM). E.g., a list of floats is not an array of doubles in memory.
It's not even a list of pointers to doubles in cpython, I believe, even though
one could conceive of a form of object reference handle/pointers with type clues
in the LSBs that could make pointing to a float object be represented exactly
identically to a C pointer to double. (Since ints are much more commonly used
that would be a waste though, I think, since you would want to use LSB bits to
encode differentiation between the most common primitive types for special handling,
and it would probably be nice to do simple integer arithmetic without needing to mask,
but this is getting to other topics ;-)

Regards,
Bengt Richter

[Antoon Pardon]

Op 2005-08-16, Peter Hansen schreef <pe***@engcorp.com>:

Antoon Pardon wrote:

Why has one made a difference in search policy for finding a
variable based on whether the variable is rebound or not
in the first place.
Do you really not understand the reason, or do you simply disagree with
it?

How can I understand something that was never explained to me. Each time
I saw this coming up people answered the technical question about the
difference between rebinding and accessing or modification. I haven't seen
anyone answer the question asnwer at this level.
It's a choice with rational thought behind it.

Then please explain this rational thought instead of
just asserting that it is present.

--
Antoon Pardon

[Terry Reedy]

"Bengt Richter" <bo**@oz.net> wrote in message
news:43*****************@news.oz.net...

Yes, the roster model works for me too, but I'm not sure I understand
your
concept of "container/room" ;-)

I only meant that if collective objects were containers of objects like
rooms are containers of people, then an object could be in only 1
collective at a time. But that is importantly not true. Therefore
collectives are not containers.

I once mistakenly thought of mathematical sets as being like boxes. Don't
know if someone else said so or if I just thought up that error on my own.
But then I realized that the box model leads to the the same counterfactual
conclusion. Therefore 'box' is a bad metaphor. Sets are rosters. The
very term 'member of' is a clue that I missed for years ;-) I hope to help
other avoid the same mistake.

The roster idea also explains how a set can be a 'member' of itself, and
how a list can include itself. Weird, perhaps, but easily possible.

The underlying problem is that 'contains' has two meanings: a room
contains people by actual presence and hence is a container. A club roster
metaphorically contains people by name (reference) as members, but not
actually, and hence is not a container even though we may speak of it as
'containing'.

Terry J. Reedy