[Python-Dev] replacing 'global'
pedronis at bluewin.ch
Tue Oct 21 21:27:14 EDT 2003
At 17:42 21.10.2003 -0700, Guido van Rossum wrote:
>(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
> > > > 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
> > 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
>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
>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
>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
> > 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' .
. suggests runtime, for compile time then maybe
(I don't like those, and personally I don't see the need to get rebinding
for closed-over variables but anyway)
another possibility is that today <name> <name> is a syntax error, so maybe
global x = 42 or
module x = 42
they would not be statements, this for symmetry would also be legal:
y = module x + 1
outer x = 42
y = g x + 1
the problems are also clear, in some other languages x y is function
More information about the Python-Dev