Sometimes it is useful to do a import to a global name inside a function. A common use case is the 'pylab' module, which must be imported *after* the backend has been set using 'matplotlib.use()'. If the backend is configuration-dependent, the statement import pylab will usually be inside a function, but the module should be available globally, so you would do global pylab import pylab While this code works (at least in CPython), the current language specification forbids it [1], so the correct code should be global pylab import pylab as _pylab pylab = _pylab I don't see why we shouldn't allow the shorter version -- it is certainly easier to read. The behaviour of pylab might be considered a questionable design choice. I've encountered the above non-conforming, but working code out in the wild several times, though, so the language specification might as well allow it. Cheers, Sven [1]: http://docs.python.org/dev/reference/simple_stmts.html#the-global-statement
Sven Marnach wrote:
I quote: Names listed in a global statement must not be defined as formal parameters or in a for loop control target, class definition, function definition, or import statement. http://docs.python.org/dev/reference/simple_stmts.html#the-global-statement I can understand that it makes no sense to declare a function parameter as global, and I can an argument in favour of optimizing for loops by ensuring that the target is always a local rather than global. But what is the rationale for prohibiting globals being used for classes, functions, and imports? It seems like an unnecessary restriction, particularly since CPython doesn't bother to enforce it. The semantics of "global x; import x" is simple and obvious. +1 on removing the unenforced prohibition on global class/def/import inside functions. -- Steven
On Wed, Apr 11, 2012 at 10:36 AM, Guido van Rossum <guido@python.org> wrote:
+1
Ditto. FWIW, I'm actually in favour of dropping everything after the "or" in that paragraph from the language spec, since we don't enforce *any* of it. Aside from formal parameter definitions (which explicitly declare local variables), name binding operations are just name binding operations regardless of the specific syntax. With global:
With nonlocal:
By contrast:
Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
On Wed, Apr 11, 2012 at 1:29 PM, Raymond Hettinger <raymond.hettinger@gmail.com> wrote:
Agreed. I created http://bugs.python.org/issue14544 to provide a location for people to object (and will share the link around a bit). Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
On 4/10/2012 8:59 PM, Nick Coghlan wrote:
I found this slightly surprising, but on checking with dis, each of the 'implicit' assignments is implemented as the equivalent of x = internal_function_call(args). (For for-loops, the assignment is within the loop.) Which is to say, each bytecode sequence ends with store_xxx where xxx is 'fast' or 'global. So now I am not surprised. -- Terry Jan Reedy
On Wed, Apr 11, 2012 at 3:08 PM, Terry Reedy <tjreedy@udel.edu> wrote:
By contrast, I already knew that CPython's underlying implementation of the name binding step was the same in all these cases, so I was surprised by the documented restriction in the language spec. I'm now wondering if the initial restriction that prompted the note in the language spec was something that existed in the pre-AST version of the compiler (I only started learning the code generation machinery when I was helping to get the AST based compiler branch ready for inclusion in Python 2.5, so I know very little about how the compiler used to work in 2.4 and earlier) Regards, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
Sven Marnach wrote:
I quote: Names listed in a global statement must not be defined as formal parameters or in a for loop control target, class definition, function definition, or import statement. http://docs.python.org/dev/reference/simple_stmts.html#the-global-statement I can understand that it makes no sense to declare a function parameter as global, and I can an argument in favour of optimizing for loops by ensuring that the target is always a local rather than global. But what is the rationale for prohibiting globals being used for classes, functions, and imports? It seems like an unnecessary restriction, particularly since CPython doesn't bother to enforce it. The semantics of "global x; import x" is simple and obvious. +1 on removing the unenforced prohibition on global class/def/import inside functions. -- Steven
On Wed, Apr 11, 2012 at 10:36 AM, Guido van Rossum <guido@python.org> wrote:
+1
Ditto. FWIW, I'm actually in favour of dropping everything after the "or" in that paragraph from the language spec, since we don't enforce *any* of it. Aside from formal parameter definitions (which explicitly declare local variables), name binding operations are just name binding operations regardless of the specific syntax. With global:
With nonlocal:
By contrast:
Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
On Wed, Apr 11, 2012 at 1:29 PM, Raymond Hettinger <raymond.hettinger@gmail.com> wrote:
Agreed. I created http://bugs.python.org/issue14544 to provide a location for people to object (and will share the link around a bit). Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
On 4/10/2012 8:59 PM, Nick Coghlan wrote:
I found this slightly surprising, but on checking with dis, each of the 'implicit' assignments is implemented as the equivalent of x = internal_function_call(args). (For for-loops, the assignment is within the loop.) Which is to say, each bytecode sequence ends with store_xxx where xxx is 'fast' or 'global. So now I am not surprised. -- Terry Jan Reedy
On Wed, Apr 11, 2012 at 3:08 PM, Terry Reedy <tjreedy@udel.edu> wrote:
By contrast, I already knew that CPython's underlying implementation of the name binding step was the same in all these cases, so I was surprised by the documented restriction in the language spec. I'm now wondering if the initial restriction that prompted the note in the language spec was something that existed in the pre-AST version of the compiler (I only started learning the code generation machinery when I was helping to get the AST based compiler branch ready for inclusion in Python 2.5, so I know very little about how the compiler used to work in 2.4 and earlier) Regards, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
participants (6)
-
Guido van Rossum -
Nick Coghlan -
Raymond Hettinger -
Steven D'Aprano -
Sven Marnach -
Terry Reedy