[Python-Dev] replacing 'global'

[Guido van Rossum]

(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/)