(Changing the subject yet again)
Plus. EVERY newbie makes the mistake of taking "global" to mean "for ALL modules" rather than "for THIS module",
Only if they've been exposed to languages that have such globals.
Actually, I've seen that happen to complete newbies too. "global" is a VERY strong word -- or at least perceived as such.
We can't expect everybody to guess the rules of the language purely based on the symbols used. But I appreciate the argument; 'global' comes from ABC's SHARE, but ABC doesn't have modules. (It does have workspaces, but AFAIR there is no communication at all between workspaces, so it isn't unreasonable that a SHAREd name in one workspace isn't visible in another workspace.)
uselessly using global in toplevel,
Which the parser should reject.
Again: can we do that in 2.4?
Submit a patch. It'll probably break plenty of code though (I bet you including Zope :-), so you'll have to start with a warning in 2.4.
I think it's not unreasonable to want to replace global with attribute assignment of *something*. I don't think that "something" should have to be imported before you can use it; I don't even think it deserves to have leading and trailing double underscores.
Using attribute assignment is my main drive here. I was doing it via import only to be able to experiment with that in today's Python;-).
You could have writen an import hook that simply inserted __globals__ in each imported module. :-)
Walter suggested 'global.x = 23' which looks reasonable; unfortunately my parser can't do this without removing the existing global statement from the Grammar: after seeing the token 'global' it must be able to make a decision about whether to expand this to a global statement or an assignment without peeking ahead, and that's impossible.
So it can't be global, as it must stay a keyword for backwards compatibility at least until 3.0. What about: this_module current_module sys.modules[__name__] [[hmmm this DOES work today, but...;-)]] __module__ ...?
__module__ can't work because it has to be a string. (I guess it could be a str subclass but that would be too perverse.) Walter and I both suggested hijacking the 'globals' builtin. What do you think of that?
If we removed global from the language, how would you spell assignment to a variable in an outer function scope? Remember, you can *not* use 'outer.x' because that already refers to a function attribute.
scope(outer).x , making 'scope' a suitable built-in factory function. I do think this deserves a built-in.
Hm. I want it to be something that the compiler can know about reliably, and a built-in function doesn't work (yet). The compiler currently knows enough about nested scopes so that it can implement locals that are shared with inner functions differently (using cells). It's also too asymmetric -- *using* x would continue to be just x. Hmm. That's also a problem I have with changing global assignment -- I think the compiler should know about it, just like it knows about *using* globals. And it's not just the compiler. I think it requires more mental gymnastics of the human reader to realize that def outer(): def f(): scope(outer).x = 42 print x return f outer()() prints 42 rather than being an error. But how does the compiler know to reserve space for x in outer's scope? Another thing is that your proposed scope() is too dynamic -- it would require searching the scopes that (statically) enclose the call for a stack frame belonging to the argument. But there's no stack by the time f gets called in the last example! (The curernt machinery for nested scopes doesn't reference stack frames; it only passes cells.)
If we have this, maybe scope could also be reused as e.g. scope(global).x = 23 ? I think the reserved keyword 'global' SHOULD give the parser no problem in this one specific use (but, I'm guessing...!).
I don't want to go there. :-) (If it wasn't clear, I'm struggling with this subject -- I think there are good reasons for why I'm resisting your proposal, but I haven't found them yet. The more I think about it, the less I like 'globals.x = 42' . --Guido van Rossum (home page: http://www.python.org/~guido/)