| msg60213 - (view) |
Author: Armin Rigo (arigo) *  |
Date: 2008-01-19 18:55 |
| Can you guess why importing the attached x.py does nothing, without printing "hello" at all? The real issue shown in that example is that 'return' and 'yield' outside a function are ignored instead of giving a SyntaxError if they are optimized away by 'if 0:'. (Hint about x.py: the yield sets the CO_GENERATOR flag before it gets optimized away. So clearly, that's a way to comment out a whole module -- just put "if 0: yield" anywhere at top-level...) |
|
|
| msg61638 - (view) |
Author: Mark Dickinson (mark.dickinson) * |
Date: 2008-01-24 16:24 |
| See also issue #1920 |
|
|
| msg80955 - (view) |
Author: Amaury Forgeot d'Arc (amaury.forgeotdarc) * |
Date: 2009-02-02 17:00 |
| This was corrected by Benjamin with r69158. Now the yield statement is still optimized away, but at least the CO_GENERATOR flag is set only when compiling a function. |
|
|
| msg80961 - (view) |
Author: Armin Rigo (arigo) * |
Date: 2009-02-02 17:11 |
| ...which does not really solve anything, as "if 0: yield" at module-level is now just ignored instead of raising a SyntaxError (e.g. like "if False: yield"). |
|
|
| msg81019 - (view) |
Author: Amaury Forgeot d'Arc (amaury.forgeotdarc) * |
Date: 2009-02-02 23:48 |
| Here is a patch that properly raises SyntaxError when 'return' or 'yield' statements appear outside a function. I did not bother to update the (deprecated) compiler package: it seems to be completely foreign to this kind of checks... >>> dis.dis(compiler.compile("return 1", "module.py", "exec")) 1 0 LOAD_CONST 1 (1) 3 RETURN_VALUE 4 LOAD_CONST 0 (None) 7 RETURN_VALUE |
|
|
| msg81023 - (view) |
Author: Benjamin Peterson (benjamin.peterson) * |
Date: 2009-02-03 01:56 |
| You should remove the error logic compile.c for "return" and "yield" in function calls. The problem with this approach is that every SyntaxError generated during bytecode compilation must be moved to earlier. For example, I can still use "break" and "continue" outside loops with your patch. The only way I can think of around this is to compile the block anyway and remove the extra code later. Maybe this optimization could be moved to the peep holer? |
|
|
| msg116917 - (view) |
Author: Mark Lawrence (BreamoreBoy) * |
Date: 2010-09-20 07:55 |
| indicates that more work is needed on this. |
|
|
| msg342464 - (view) |
Author: Stéphane Wirtel (matrixise) * |
Date: 2019-05-14 14:22 |
| With the last 2.7 and 3.7, I can import the x module and the 'hello' is automatically printed. Python 2.7.15 (default, Oct 15 2018, 15:26:09) [GCC 8.2.1 20180801 (Red Hat 8.2.1-2)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import x hello Python 3.7.3 (default, Apr 2 2019, 06:55:20) [GCC 8.3.1 20190223 (Red Hat 8.3.1-2)] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import x hello >>> content = open('x.py').read() >>> import dis >>> dis.dis(content) 1 0 LOAD_NAME 0 (print) 2 LOAD_CONST 0 ('hello') 4 CALL_FUNCTION 1 6 POP_TOP 3 8 LOAD_CONST 1 (None) 10 RETURN_VALUE but because I am not sure about this issue, I prefer to ask Serhiy. Can we close it? Thank you |
|
|
| msg342525 - (view) |
Author: Pablo Galindo Salgado (pablogsal) * |
Date: 2019-05-14 23:27 |
| The issue is not fixed. The problem is that this still allows invalid syntax because the code is optimized away: def f(): if 0: break print("Hello") f() |
|
|
| msg342555 - (view) |
Author: Serhiy Storchaka (serhiy.storchaka) * |
Date: 2019-05-15 09:02 |
| The drawback of compiling the dead code is adding cells for unneeded constants and local variables. Also it can create less optimal code for jumps. |
|
|
| msg342559 - (view) |
Author: Pablo Galindo Salgado (pablogsal) * |
Date: 2019-05-15 10:00 |
| >The drawback of compiling the dead code is adding cells for unneeded constants and local variables. Also it can create less optimal code for jumps. Is unlikely that this situation arises often enough that this is a concern. We would be sacrificing correctness for speed and I think that is an error. If there is a more optimal approach I'm happy to implement it. |
|
|
| msg342705 - (view) |
Author: Pablo Galindo Salgado (pablogsal) * |
Date: 2019-05-17 10:37 |
| New changeset af8646c8054d0f4180a2013383039b6a472f9698 by Pablo Galindo in branch 'master': bpo-1875: Raise SyntaxError in invalid blocks that will be optimised away (GH-13332) https://github.com/python/cpython/commit/af8646c8054d0f4180a2013383039b6a472f9698 |
|
|
| msg342706 - (view) |
Author: miss-islington (miss-islington) |
Date: 2019-05-17 10:59 |
| New changeset 85ed1712e428f93408f56fc684816f9a85b0ebc0 by Miss Islington (bot) in branch '3.7': bpo-1875: Raise SyntaxError in invalid blocks that will be optimised away (GH-13332) https://github.com/python/cpython/commit/85ed1712e428f93408f56fc684816f9a85b0ebc0 |
|
|
| msg345684 - (view) |
Author: Serhiy Storchaka (serhiy.storchaka) * |
Date: 2019-06-15 15:19 |
| The issue is not fixed yet. The compiler now rejects if 0: return but it still accepts if 1: pass else: return while 0: return |
|
|
| msg347350 - (view) |
Author: Ned Deily (ned.deily) * |
Date: 2019-07-05 14:22 |
| See also discussion in Issue37500. |
|
|