[Python-Dev] replacing 'global'

[Guido van Rossum]

[Neal]
> >         def reset_foo():
> >             global foo = []     # declare as global and do assignment

[Alex]
> Indeed, you can see 'global', in this case, as a kind of "operator
> keyword", modifying the scope of foo in an assignment statement.
> 
> I really have two separate peeves against global (not necessarily
> in order of importance, actually):
> 
> -- it's the wrong keyword, doesn't really _mean_ "global"

I haven't heard anyone else in this thread agree with you on that
one.  I certainly don't think it's of earth-shattering ugliness.

> -- it's a "declarative statement", the only one in Python (ecch)
>    (leading to weird uncertainty about where it can be placed)

I'd be happy to entertain proposals for reasonable restrictions on
where 'global' can be placed.  (Other placements would have to be
deprecated at first.)

> -- "side-effect" assignment to globals, such as in def, class &c
>    statements, is quite tricky and error-prone, not useful

Agreed; nobody uses these, but again this can be fixed if we want to
(again we'd have to start deprecating existing use first).

Note that this is also currently allowed and probably shouldn't:

  def f():
    global x
    for x in ...:
      ...

> Well, OK, _three_ peeves... usual Spanish Inquisition issue...:-)
> 
> Your proposal is quite satisfactory wrt solving the second issue,
> from my viewpoint.  It would still create a unique-in-Python
> construct, but not (IMHO) a problematic one.

Well, *every* construct is "unique in Python", isn't it?  Because
Python has only one of each construct, in line with the TOOWTDI zen.

Or do you mean "not seen in other languages"?  I'd disagree -- lots of
languages have something similar, e.g. "int x = 5;" in C or "var x =
5" in JavaScript.  IMO, "global x = 5" is sufficiently similar that it
will require no time to learn.

> As you point out,
> it _would_ be more concise than having to separately [a] say
> foo is global then [b] assign something.  It would solve any
> uncertainty regarding placement of 'global', and syntactically
> impede using global variables in "rebinding as side-effect" cases
> such as def &c, so the third issue disappears.
> 
> The first issue, of course, is untouched:-).  It can't be touched
> without choosing a different keyword, anyway.
> 
> So, with 2 resolutions out of 3, I do like your idea.

I don't think that Neal's proposal solves #3, unless 'global x = ...'
becomes the *only* way.  Also, I presume that the following:

  def f():
    global x = 21
    x *= 2
    print x

should continue to be value, and all three lines should reference the
same variable.

But #3 is moot IMO, it can be solved without mucking with global at
all, by simply making the parser reject 'class X', 'def X', 'import X'
and 'for X' when there's also a 'global X' in effect.  Piece of cake.

> However, I don't think we can get there from here.  Guido has
> explained that the parser must be able to understand a statement
> that starts with 'global' without look-ahead; I don't know if it can
> keep accepting, for bw compat and with a warning, the old
>     global xx
> while also accepting the new and improved
>     global xx = 23

There is absolutely no problem recognizing this.

> But perhaps it's not quite as hard as the "global.xx = 23" would
> be.  I find Python's parser too murky & mysterious to feel sure.

If you can understand what code can be recognized by a pure recursive
descent parser with one token lookahead and no backtracking, you can
understand what Python's parser can handle.

> Other side issues: if you rebind a module-level xx in half a
> dozen places in your function f, right now you only need ONE
> "global xx" somewhere in f (just about anywhere); with your
> proposal, you'd need to flag "global xx = 23" at each of the
> several assignments to that xx.  Now, _that suits me just
> fine_: indeed, I LOVE the fact that a bare "xx = 23" is KNOWN
> to set a local, and you don't have to look all over the place for
> declarative statements that might affect its semantics

You may love this for assignments, but for *using* variables there is
already no such comfort.  Whether "print xx" prints a local or global
variable depends on whether there's an assignment to xx anywhere in
the same scope.  So I don't think that is a very strong argument.

> (hmmm,
> perhaps a 4th peeve vs global, but I see it as part and parcel
> of peeve #2:-).  But globals-lovers might complain that it makes
> using globals a TAD less convenient.  (Personally, I would not
> mind THAT at all, either: if as a result people use 10% fewer
> globals and replace them with arguments or classes etc, I think
> that will enhance their programs anyway;-).
> 
> 
> So -- +1, even though we may need a different keyword to
> solve [a] the problem of getting there from here AND [b] my
> peeve #1 ...:-).

--Guido van Rossum (home page: http://www.python.org/~guido/)