Q: Python 2.0 preliminary features?

[Jeremy Hylton]

>>>>> "MS" == skaller  <skaller at maxtal.com.au> writes:

  [Earlier, I wrote:]
  >>     def f():
  >>        x = 0
  >>        def g():
  >>           global x
  >>           def h():
  >>             global x
  >>             x = 1
  >> 
  >> At compile time, you should know which scopes have local
  >> variables named x and which have global declarations for x.  If g
  >> does not have a local variable named x, then the global
  >> declaration in h can't sensibly mean the local variable x in g's
  >> scope.
  >> 
  MS> 	Sure it can!! This is standard Python:

  MS> 	def q(): 
  MS>       global x 
  MS>       x = 1

  MS> Here, there is no 'global' variable x, it is in fact created by
  MS> executing q. There is no way to 'know' which scope a nested
  MS> function's 'global' statement refers to without a convention.

The top-level scope is a special case.  At compile-time, you should
also know whether the function is defined at the top-level or is
nested within another function.

  MS> The Python convention is 'module scope, always', which also
  MS> applies to all non-local variables on reading.

I'm suggesting a different convention -- nearest enclosing scope or
top-level if no enclosing scope creates a binding.

  MS> However, there is a new factor here I overlooked: a function can
  MS> gave a local variable that is NOT visible in the function, not
  MS> even in an 'exec': one which is local because it is declared
  MS> global in a function nested in it.

Hadn't thought about that particular wrinkle, but I'd be inclined to
include it in part of the top-level special case.  You could outlaw
the creation of new bindings from enclosed function definitions and
require that a binding be created explicitly -- top-level excluded.
I suppose that isn't terribly Pythonic...

but-neither-is-global-decls-in-every-function-ly yr's,
Jeremy