global statements outside functions/methods should raise SyntaxError
Python currently accepts global statements at the top level:
global foo
Beside being a meaningless operation, this might lead unexperienced user to make mistakes like:
foo = 5 global foo # make foo global def func(): ... print foo # access the global foo ... func() 5 # it works!
"global foo" should raise a SyntaxError, similarly to what already happens with "return":
return foo File "<stdin>", line 1 SyntaxError: 'return' outside function
I opened an issue on the tracker (http://bugs.python.org/issue7329) and Benjamin suggested to discuss this here. The test he mentioned is in test_global.py: def test4(self): prog_text_4 = """\ global x x = 2 """ # this should work compile(prog_text_4, "<test string>", "exec") It just says that "it should work" but it doesn't say /why/. Any thoughts?
Ezio Melotti wrote:
Python currently accepts global statements at the top level:
global foo
Beside being a meaningless operation, this might lead unexperienced user to make mistakes like:
foo = 5 global foo # make foo global def func(): ... print foo # access the global foo ... func() 5 # it works!
"global foo" should raise a SyntaxError, similarly to what already happens with "return":
return foo File "<stdin>", line 1 SyntaxError: 'return' outside function
I opened an issue on the tracker (http://bugs.python.org/issue7329) and Benjamin suggested to discuss this here. The test he mentioned is in test_global.py:
def test4(self): prog_text_4 = """\ global x x = 2 """ # this should work compile(prog_text_4, "<test string>", "exec")
It just says that "it should work" but it doesn't say /why/.
Well, personally I think it would be a good thing if this raised an exception during bytecode compilation - but it would fall under the moratorium and have to wait a few years. On the other hand it should be easy to get PyLint to include a checker for this and they are very responsive to feature requests. All the best, Michael
Any thoughts?
_______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.u...
-- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog
2009/11/15 Michael Foord <fuzzyman@voidspace.org.uk>:
Well, personally I think it would be a good thing if this raised an exception during bytecode compilation - but it would fall under the moratorium and have to wait a few years.
It could probably be considered a bug, though, since the global statement in that case silently has absolutely no effect. -- Regards, Benjamin
Benjamin Peterson <benjamin <at> python.org> writes:
2009/11/15 Michael Foord <fuzzyman <at> voidspace.org.uk>:
Well, personally I think it would be a good thing if this raised an exception during bytecode compilation - but it would fall under the moratorium and have to wait a few years.
It could probably be considered a bug, though, since the global statement in that case silently has absolutely no effect.
Indeed, and it's not like other implementations would be at a disadvantage if they didn't implement this error. Warning that the construct is meaningless can be helpful, especially for refugees from other languages. Regards Antoine.
Benjamin Peterson wrote:
2009/11/15 Michael Foord <fuzzyman@voidspace.org.uk>:
Well, personally I think it would be a good thing if this raised an exception during bytecode compilation - but it would fall under the moratorium and have to wait a few years.
It could probably be considered a bug, though, since the global statement in that case silently has absolutely no effect.
It wouldn't be adding a new feature, but it would be changing the behaviour of programs that currently have 'global' outside a function. Perhaps, due to the moratorium, there should be a warning before it's actually corrected.
Ezio Melotti wrote:
Python currently accepts global statements at the top level:
I opened an issue on the tracker (http://bugs.python.org/issue7329) and Benjamin suggested to discuss this here. The test he mentioned is in test_global.py:
def test4(self): prog_text_4 = """\ global x x = 2 """ # this should work compile(prog_text_4, "<test string>", "exec")
It just says that "it should work" but it doesn't say /why/.
Any thoughts?
I make the same suggestion a couple of years ago, either this list or Py3k list, after newby reported 'problem' on python-list expecting module-level global to do something. Guido rejected it on the basis that he wanted to minimized differences between module code and function code.
On Sun, Nov 15, 2009 at 12:38 PM, Terry Reedy <tjreedy@udel.edu> wrote:
Ezio Melotti wrote:
Python currently accepts global statements at the top level:
I opened an issue on the tracker (http://bugs.python.org/issue7329) and Benjamin suggested to discuss this here. The test he mentioned is in test_global.py:
def test4(self): prog_text_4 = """\ global x x = 2 """ # this should work compile(prog_text_4, "<test string>", "exec")
It just says that "it should work" but it doesn't say /why/.
Any thoughts?
I make the same suggestion a couple of years ago, either this list or Py3k list, after newby reported 'problem' on python-list expecting module-level global to do something. Guido rejected it on the basis that he wanted to minimized differences between module code and function code.
That example should work because you could pass it to exec()/eval() with separate dicts for locals and globals: $ python3.0 Python 3.0 (py3k:67506, Dec 3 2008, 10:12:04) [GCC 4.0.1 (Apple Inc. build 5484)] on darwin Type "help", "copyright", "credits" or "license" for more information.
glo = {} lo = {} so = 'global x; x = 2' co = compile(so, '', 'exec') exec(co, glo, lo) glo['x'] ['x'] exec('x = 3', glo, lo) glo['x'] 2 lo['x'] 3
-- --Guido van Rossum (python.org/~guido)
participants (7)
-
Antoine Pitrou -
Benjamin Peterson -
Ezio Melotti -
Guido van Rossum -
Michael Foord -
MRAB -
Terry Reedy