[Python-Dev] Re: closure semantics

[Guido van Rossum]

> Is there any good reason to ever use globals anywhere other than as
> the first statement (after doc string) of a function?

If the use of the global is fairly localized, I sometimes like to have
the global declaration immediately proceed the first use, assuming all
other uses are in the same indented block.  (This means that I
sometimes *do* have global inside flow control, but then all uses are
also inside the same branch.)

But I'm not sure this is a *good* reason.

> If not, could its usage be so restricted (like __future__ import)?

This would break way too much stuff.  It would have been a good idea
for 0.1.  But then I was trying to keep the grammar small
while keeping syntactic checks out of the compilation phase if at all
possible, and I thought "screw it -- if import can go anywhere, so can
global."

> > > Plus. EVERY newbie makes the mistake of taking "global" to mean
> > > "for ALL modules" rather than "for THIS module",
> 
> Part of my brain still thinks that, and another part has to say,
> 'no, just modular or mod_vars()'.
> 
> > Only if they've been exposed to languages that have such globals.
> 
> Like Python with __builtins__?  which I think of as the true globals.

Hardly, since they aren't normally thought of as variables.

> Do C or Fortran count as such a source of 'infection'?

C, definitely -- it has the concept and the terminology.  In Fortran,
it's called common blocks (similar in idea to ABC's SHARE).

> > > uselessly using global in toplevel,
> >
> > Which the parser should reject.
> 
> Good.  The current nonrejection sometimes leads beginners astray
> because they think it must be doing something.

Just like

   x + 1

I suppose.  I'm sure PyChecker catches this.

> While I use global/s() just fine, I still don't like the names.  I
> decided awhile ago that they must predate import, when the current
> module scoop would have been 'global'.

No, they were both there from day one.

Frankly, I don't think in this case newbie confusion is enough of a
reason to switch from global to some other keyword of mechanism.

Yes, this means I'm retracting my support for Alex's
"replace-global-with-attribute-assignment" proposal -- Jeremy's
objection made me realize why I don't like it much.

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