[Python-Dev] replacing 'global'

[Samuele Pedroni]

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
>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' .

. suggests runtime, for compile time then maybe

global::x=42
module::x=42

outer::x=42

(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

then

outer x = 42

and also

y = g x + 1

the problems are also clear, in some other languages x y is function 
application, etc..