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

 

[D H]

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?

It is likely that more people would find module or modulescope confusing.

Plus module has a different customary meaning already:

import <module>

 

[Atila Olah]

I think D H is right. Or even if you'd find out that most of the people
would better like 'modulescope' or 'module', (what is, i think,
imposible), you'd destroy the backward-compatibility with older
versions of Puthon if you implement it. But it won't be implemented.
Trust me.

 

[John Roth]

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

A much better idea would be to fix the underlying
situation that makes the global statement necessary.

I doubt if this is going to happen either, though.

John Roth

 

[Terry Reedy]

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

I did to at first.

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

Global is an somewhat short adjective that plausibly becomes a noun when
pluralized. That is hard to match. I have thought of 'modular' as the
actual meaning of 'global', but 'modulars' does not sound as good to me.

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

You are the first people I remember making at least the 'modulescope'
suggestion. Searching the newsgroup archive at Google would make sure ;-).

Is this a candidate for Python 3000 yet?

Unlikely. I suspect that global meaning global to the module (as opposed to
the collection of modules or compilation units) is established CS usage.

Terry J. Reedy

 

[seberino]

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.

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

 

[seberino]

Python 3000 is not worried about backward compatibility.
It is worried more about what is *best* and getting it done.
Trust me.

Let me ask an academic question....Is 'global' the
*best* choice of all choices in Webster's dictionary?

If it is then I'll give up and go home. If not then well.....

Chris

 

[seberino]

Your solution is the best of them all. However, I don't
have the foggiest idea how it would be accomplished.

Are you *sure* you can change design so that there
is no need for a keyword like 'global'? Please enlighten
me. I'd really appreciate it.

Chris

 

[seberino]

I appreciate your comments. You give reasons why you
think 'global' is a good idea.

Are you sure that 'global' is widely assumed to mean
global to a *file* in proper CS theory? Coming from C....I assumed
'global' meant global to ENTIRE EXECUTABLE!?!? You
even admitted you also thought 'global' was confusing in past!
So how can you say you think CS community in general won't
have any problem like we BOTH did????

Chris

 

[Mike Meyer]

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.

<mike

 

[Joseph Garvin]

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

Hmm.. instead of 'global', how about 'outside' ? It seems a bit more
intuitive to me because it suggests that you mean, "the variable defined
outside this scope" or outside any nestedness.

But then again it could be confused to mean "just one scope above this
one" which isn't necessarily module scope (nested functions, etc.)...
still, might be less confusing than 'global'.

Another alternative to having to say "global var" would be to use some
sort of indicator that you want the global with each usage, like,
"global.var" or "outside.var"

 

[Terry Reedy]

Are you sure

If I were, I would not have started the statement 'I suspect...'. I do not
insert such words accidentally.

TJR

 

[Dennis Lee Bieber]

I appreciate your comments. You give reasons why you
think 'global' is a good idea.

Are you sure that 'global' is widely assumed to mean
global to a *file* in proper CS theory? Coming from C....I assumed
'global' meant global to ENTIRE EXECUTABLE!?!? You

Considering that "global" is only useful within the body of a
"def" block would seem to imply that it is something special within the
file and not program-wide...

If "global" were used at the top of a module, then I could see
that interpretation. It would be similar to a named COMMON in FORTRAN --

global x
equivalent to
COMMON /X/ x

{My college FORTRAN IV actually /did/ have a "GLOBAL" statement which
functioned in just that way: each variable specified became the only
content of a common block named the same as the variable}

--

 

[John Roth]

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.

You've got half of the answer. The other half is to have the editor/ide
translate the lexical cues into color coding and hide the lexical cues.

It's not going to happen because the Python community is fat and happy,
and is not seeing the competition moving up on the outside. Characteristics
that make a great language one day make a mediocre one a few years
later, and make a has-been a few years after that.

John Roth

 

[Peter Hansen]

It's not going to happen because the Python community is fat and happy,
and is not seeing the competition moving up on the outside. Characteristics
that make a great language one day make a mediocre one a few years
later, and make a has-been a few years after that.

And here I thought that was the point of Python 3000. To let the
community produce a much improved language while avoiding the problems
caused by too much change occurring while people are trying to get
useful things done with what the language is _now_. The competition
(and let's see a description of just what that means, too) probably has
the dual advantage of newness and a small, hackerish community that is
more than happy to see rapid and radical change. You're right -- as
with the stereotypical large/slow vs. small/agile company motif -- that
smaller and more agile will pass larger and slow "on the outside", but
you're wrong if you think that means the larger-slower entity should
drop what it's been doing so well and try to compete entirely on the
smaller-faster entity's own ground.

BTW, I think "large and stable" would have been less offensive than "fat
and happy", but perhaps you meant to imply we're both lazy and
complacent, rather than just satisfied with something that works and not
inclined to shoot for moving targets every working day. If so, I'm not
sure why you'd say that, since the evidence doesn't support it.


-Peter

 

[Kay Schluehr]

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

Maybe a solution would be best that is able to resolve shadowing of a
variable in an explicit manner.

Example. you might have the following nested function:

x = 0
def h():
x = 1 # module scoped x will be shadowed
def g():
x = 2 # module scoped x and h's local x will be
shadowed
def f():
print x # printing x defined locally in g
f()
g()

The module level x is always accessible from each inner function using
the global keyword but it is not possible to access x defined locally
in h from f.

Two hypothetical variants using an "unshadow operator" & explicitely:

x = 0
def h():
x = 1
def g():
x = 2
def f():
print &x # unshadowing x defined in h
f()
g()


x = 0
def h():
x = 1
def g():
x = 2
def f():
print &&x # unshadowing x defined on module level
f()
g()

Since we can always shadow some module scoped variable defining a local
one we might create a side-effect binding values to the unshadowed
name:

x = 0
def f():
x = 1
&x = 7
7

Regards,
Kay

 

[Paolino]

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

I don't think the global keyword is useful actually.

What's so special in a module nemespace to be priviledged like that.

The point IMO is accessing names defined somewhere in the enclosing
namespaces.

def enclosing():
var=2
def enclosed():
outer var=4

this is the base of something useful.

as it is now you neeed

def enclosing():
class Var:_=2
def enclosed():
Var._=4
or like others suggested

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?

I think there is only one or none possible solution to an 'outer'
statement which is the first bound name matching the 'outer' vars name
in the chain of enclosing namespaces.

Why every instance doesn't point to its namespace and every namespace to
its namespace? Unpythonic ?

Illogicities to my eyes or at least non-linerities that makes 'global'
an interesting strangeness to talk about.

And that namespaces should start being easy sooner or later.


Regards Paolino





___________________________________
Yahoo! Mail: gratis 1GB per i messaggi e allegati da 10MB
http://mail.yahoo.it

 

[Peter Hansen]

(e-mail address removed) 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.

(Those who don't understand the difference between "rebinding a name"
and "modifying an object" will need to figure out that distinction
before they can participate much in a discussion about Python scopes, I
think.)

-Peter

 

[John Roth]

And here I thought that was the point of Python 3000. To let the
community produce a much improved language while avoiding the problems
caused by too much change occurring while people are trying to get useful
things done with what the language is _now_. The competition (and let's
see a description of just what that means, too) probably has the dual
advantage of newness and a small, hackerish community that is more than
happy to see rapid and radical change. You're right -- as with the
stereotypical large/slow vs. small/agile company motif -- that smaller and
more agile will pass larger and slow "on the outside", but you're wrong if
you think that means the larger-slower entity should drop what it's been
doing so well and try to compete entirely on the smaller-faster entity's
own ground.

Maybe "fat and happy" wasn't the best choice of words (and maybe
Extreme Programming wasn't Kent Beck's best choice of words either.)

However. I see nothing in the existing Python 3000 PEP that does
anything other than inspire a yawn. Sure, it's a bunch of cleanup, and
some of it is definitely needed. What I don't see is the inspired leap
forward that will once again put Python in the forefront rather than
simply being one choice among many.

What I want to see in Python 3000 is an AST based language
that lets the editors do the pretty printing. Do you want automatic
indenting or would you prefer end statements? It's an editor formatting
option. The AST neither knows or cares. Don't want to see self?
Editor formatting option. The AST knows what scope each
identifier belongs to because it's right there in the text. No need
for rules that you have to learn, sometimes the hard way.

Want to see type inference? I haven't a clue how to do it in a
dynamic language like Python, but an AST based language is a
perfect test bed for experimentation.

What's good about other languages? I see very little here
that is an examination of what Smalltalk, Ruby, Perl, etc.
seem to have gotten right and could be moved into Python
to good effect.

Talk to people who've moved from Python to Ruby, or to
some other language. Ask them why, if Python is so great,
what's even greater in that other language. If you still don't
understand, you might want to read this:

http://martinfowler.com/bliki/CollectionClosureMethod.html

Look at Pep 8. It's a compendium of coding standards
for the standard library. So far, ok. Coding standards
are generally good. But why does Guido like underscores
in method names? I know there was (and the accent is
on the word was) some research, refuted well over a decade
ago, that mixedCase was hard to read. The fact is that
_all_ conventions for separating words are hard to read
until the brain grows new synapses that handle it. Of the
options, no separation is the hardest to handle. There are
reasons why ancient texts, which had neither word
separators nor punctuation, have very contentious translations.

I find the notion that there should be one obviously right way
to do something to be a good design principle, so why isn't
there a single supported GUI library? If I'm over in Java-land,
just about everything comes with a GUI. Python ships with a
lot of little demonstration and utility scripts - none of which has
a GUI.

Part of the tone here is because of the PEP 208 voting
process. From day one, I knew it was going to fail.
Anyone who stood back and looked at the process, rather
than getting into the detail, knew it was going to fail. There
was no way that the Python community was going to come
up with a simple majority in favor of one proposal. None.
And it was obvious from the start.

And the sad fact is that a proposition of the form: "We
want a conditional expression; Guido should pick the
syntax he finds the least obnoxious and get on with it"
would have passed. Overwhelmingly.

I came across a better voting process (Condorcet)
later. Unfortunately it was later or I would have
suggested it.

Why the jihad (and I'm using the word advisedly)
against the map, filter and reduce operators?
It seems to be completely irrational from my
viewpoint. I've seen the arguements, and they
make no sense.

BTW, I think "large and stable" would have been less offensive than "fat
and happy", but perhaps you meant to imply we're both lazy and complacent,
rather than just satisfied with something that works and not inclined to
shoot for moving targets every working day. If so, I'm not sure why you'd
say that, since the evidence doesn't support it.

I'm not suggesting shooting at a moving target. I'm suggesting
getting the head out of the sand, looking at trends, and figuring
out the _large_ steps to take next, not the nickle and dime fixups
that are the only things I see in PEP 3000. (Not to say that some
of them aren't going to be a lot of work. Some of them are.)

I came back from Agile2005 last week. The open space session
on Ruby was maybe 5 times as large as the one on Python. And
both of them were kind of an afterthought. Look at the OSCon
blogs. There were a number of hardcore Python people there.
They couldn't get into Ruby sessions because they were jammed.
Standing room only.

There's a report out that the "scripting languages" in general are
losing mindshare big time in Europe, Africa and the east in general.
In fact, everywhere except in North America. I'm generally somewhat
skeptical of these reports unless I can see the methodology, but it's
definitely a data point.

Another thing that stands out: the explicit versus dynamic typing debate
has moved on from program correctness (which is a wash) to
other areas that explicit (or derived) type information can be used
for. I see this in PyFit: the languages where explicit type information
is available by reflection have cleaner implementations. The languages
with dynamic typing all have to deal with the fact that they can't get
type information by reflection, and it's a diverse mess.

The world is moving on, in ways that I think you're not seeing.
And Python is standing still in many of those same ways.

John Roth





John Roth

 

[John Roth]

I don't think the global keyword is useful actually.

What's so special in a module nemespace to be priviledged like that.

The point IMO is accessing names defined somewhere in the enclosing
namespaces.

The issue isn't _accessing_ the module namespace. It's
binding to identifiers in the module namespace.

The reason is that _assigning_ to an identifier in a
function or method makes that identifier local, so
there needs to be a simply way of saying that you
want to be able to assign to an identifier in the
module namespace. (There's already a more
complicated way: use the global() built-in function.)

John Roth