classification
Title: "exec(a, b, c)" not the same as "exec a in b, c" in nested functions
Type: behavior Stage: resolved
Components: Interpreter Core Versions: Python 2.7
process
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: djc Nosy List: Arfrever, Neil Muller, benjamin.peterson, brett.cannon, djc, georg.brandl, gvanrossum, ncoghlan, python-dev, rjordens, terry.reedy, vstinner
Priority: normal Keywords: patch

Created on 2014-05-28 08:47 by rjordens, last changed 2014-08-10 12:37 by ncoghlan. This issue is now closed.

Files
File name Uploaded Description Edit
bug21591.patch djc, 2014-07-24 08:01
Messages (16)
msg219259 - (view) Author: Robert Jordens (rjordens) * Date: 2014-05-28 08:47
According to the documentation the "exec a in b, c" is equivalent to "exec(a, b, c)". But in the testcase below the tuple form causes a SyntaxError while the statement form works fine.


diff -r e770d8c4291c Lib/test/test_compile.py
--- a/Lib/test/test_compile.py	Tue May 27 03:30:44 2014 -0400
+++ b/Lib/test/test_compile.py	Wed May 28 02:45:31 2014 -0600
@@ -90,6 +90,22 @@
         with self.assertRaises(TypeError):
             exec("a = b + 1", g, l) in g, l
 
+    def test_nested_qualified_exec(self):
+        # Can use qualified exec in nested functions.
+        code = ["""
+def g():
+    def f():
+        if True:
+            exec "" in {}, {}
+        """, """
+def g():
+    def f():
+        if True:
+            exec("", {}, {})
+        """]
+        for c in code:
+            compile(c, "<code>", "exec")
+
     def test_exec_with_general_mapping_for_locals(self):
 
         class M:


SyntaxError: unqualified exec is not allowed in function 'f' it is a nested function (<code>, line 5)
msg219417 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) Date: 2014-05-30 19:33
The exception appears to be intentional, though I do not know what a 'qualified' exec would be. But since the tuple form is intended to mimic 3.x exec, and since a reduced version of your example

c = '''
def g():
    def f():
        if True:
            exec("", {}, {})
'''
compile(c, "<code>", "exec")

runs fine in 3.4, I agree that this appears to be a 2.7 compiler bug.
msg223680 - (view) Author: Guido van Rossum (gvanrossum) * (Python committer) Date: 2014-07-22 18:30
This does appear to be a bug. Please research the C code that originates the error message -- there's probably a simple logic mistake.
msg223701 - (view) Author: Neil Muller (Neil Muller) Date: 2014-07-22 21:25
Poking at the source of the error suggests the problem is in symtable.c:

The offending logic looks to be (around line 1124 in python 2.7 at revision 91767:4cef7b0ec659):

if (s->v.Exec.globals) {
   ...
}
else
{
   st->st_cur->ste_unoptimized |= OPT_BARE_EXEC;
}

since OPT_BARE_EXEC is the flag that triggers the exception.

As far as I can see, this makes no provision for the exec() case, and only avoids setting OPT_BARE_EXEC if globals is specified using the old syntax.
msg223814 - (view) Author: Dirkjan Ochtman (djc) * (Python committer) Date: 2014-07-24 08:01
I came up with a patch that shifts the compatibility hack we have for the tuple form of exec from run-time (in exec_statement()) to the CST-to-AST transformation (in ast_for_exec_stmt()). It seems to pass the tests (including the ones Robert pasted in here). Please review.
msg223816 - (view) Author: Dirkjan Ochtman (djc) * (Python committer) Date: 2014-07-24 08:02
Oh, one specific question: I'm not sure if I should free the "old" expr1 (the top-level exec value) before overwriting it with the new one.
msg224228 - (view) Author: Roundup Robot (python-dev) (Python triager) Date: 2014-07-29 15:25
New changeset 33fb5600e9a1 by Dirkjan Ochtman in branch '2.7':
Issue #21591: Handle exec backwards compatibility in the AST builder.
http://hg.python.org/cpython/rev/33fb5600e9a1

New changeset 6c47c6d2033e by Robert Jordens in branch '2.7':
Issue #21591: add test for qualified exec in tuple form.
http://hg.python.org/cpython/rev/6c47c6d2033e
msg224229 - (view) Author: Dirkjan Ochtman (djc) * (Python committer) Date: 2014-07-29 15:27
Thanks to Victor Stinner for the review!
msg224787 - (view) Author: Arfrever Frehtes Taifersar Arahesis (Arfrever) * (Python triager) Date: 2014-08-04 23:39
Commit 33fb5600e9a1 causes 1 test failure in test suite of py (https://pypi.python.org/pypi/py).
Test suite of py requires pytest (https://pypi.python.org/pypi/pytest)
The failing test (test_excinfo_no_python_sourcecode) requires Jinja (https://pypi.python.org/pypi/Jinja2) and is skipped otherwise.
This test also passes with Python 3.*.

Output with py 1.4.23, pytest 2.6.0 and Jinja 2.7.3:

$ python2.7 -m pytest testing/code/test_excinfo.py
==================================================================== test session starts ====================================================================
platform linux2 -- Python 2.7.9 -- py-1.4.23 -- pytest-2.6.0
collected 71 items 

testing/code/test_excinfo.py ....................F..................................................

========================================================================= FAILURES ==========================================================================
_____________________________________________________________ test_excinfo_no_python_sourcecode _____________________________________________________________

tmpdir = local('/tmp/pytest-0/test_excinfo_no_python_sourcec0')

    def test_excinfo_no_python_sourcecode(tmpdir):
        #XXX: simplified locally testable version
        tmpdir.join('test.txt').write("{{ h()}}:")
    
        jinja2 = py.test.importorskip('jinja2')
        loader = jinja2.FileSystemLoader(str(tmpdir))
        env = jinja2.Environment(loader=loader)
>       template = env.get_template('test.txt')

testing/code/test_excinfo.py:290: 
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
/usr/lib64/python2.7/site-packages/jinja2/environment.py:791: in get_template
    return self._load_template(name, self.make_globals(globals))
/usr/lib64/python2.7/site-packages/jinja2/environment.py:765: in _load_template
    template = self.loader.load(self, name, globals)
/usr/lib64/python2.7/site-packages/jinja2/loaders.py:135: in load
    globals, uptodate)
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

cls = <class 'jinja2.environment.Template'>, environment = <jinja2.environment.Environment object at 0x7f0ed6f26f10>
code = <code object <module> at 0x7f0ed6f2d930, file "/tmp/pytest-0/test_excinfo_no_python_sourcec0/test.txt", line 1>
globals = {'cycler': <class 'jinja2.utils.Cycler'>, 'dict': <function <lambda> at 0x7f0ed73c97d0>, 'joiner': <class 'jinja2.utils.Joiner'>, 'lipsum': <function generate_lorem_ipsum at 0x7f0ed7835398>, ...}
uptodate = <function uptodate at 0x7f0ed6f22ed8>

    @classmethod
    def from_code(cls, environment, code, globals, uptodate=None):
        """Creates a template object from compiled code and the globals.  This
            is used by the loaders and environment to create a template object.
            """
        namespace = {
            'environment':  environment,
            '__file__':     code.co_filename
        }
>       exec(code, namespace)
E       TypeError: exec: arg 1 must be a string, file, or code object

/usr/lib64/python2.7/site-packages/jinja2/environment.py:917: TypeError
================================================================== short test summary info ==================================================================
FAIL testing/code/test_excinfo.py::test_excinfo_no_python_sourcecode
============================================================ 1 failed, 70 passed in 1.66 seconds ============================================================
msg224792 - (view) Author: Nick Coghlan (ncoghlan) * (Python committer) Date: 2014-08-05 01:27
I suspect there may also be a problem if executing pyc code generated the old way (this patch didn't bump the magic number, and doesn't really need to, so that case still needs to be handled).

Restoring the runtime check should cover it (the test can craft a suitable AST by hand rather than going through the now updated compiler)
msg225107 - (view) Author: Dirkjan Ochtman (djc) * (Python committer) Date: 2014-08-09 18:11
I can take a look at the py failure next week.

Keeping the run-time compatibility code seems sensible, but I'm not sure if it'd fix the py test?

I don't think reverting the changes at this point is warranted.
msg225120 - (view) Author: Nick Coghlan (ncoghlan) * (Python committer) Date: 2014-08-09 23:58
Agreed reverting isn't necessary - main thing is to figure out what went wrong in the py test suite and come up with a new test case that covers it.

The reason I suspect it's the missing runtime check that's causing the py problem is because (as far as I am aware), Jinja2 generates AST constructs directly and compiles those, and thus may be relying on the runtime check. It's just a theory, though.
msg225121 - (view) Author: Roundup Robot (python-dev) (Python triager) Date: 2014-08-10 02:40
New changeset 0e9b023078e6 by Benjamin Peterson in branch '2.7':
restore runtime exec test (#21591)
http://hg.python.org/cpython/rev/0e9b023078e6
msg225127 - (view) Author: Arfrever Frehtes Taifersar Arahesis (Arfrever) * (Python triager) Date: 2014-08-10 08:21
test_excinfo_no_python_sourcecode of py now passes.
msg225135 - (view) Author: Dirkjan Ochtman (djc) * (Python committer) Date: 2014-08-10 09:57
Thanks, Benjamin, for reverting the run-time bits.
msg225139 - (view) Author: Nick Coghlan (ncoghlan) * (Python committer) Date: 2014-08-10 12:37
Given that our test suite missed the regression originally, it would be
nice to have a test case that directly built an AST that relies on the
runtime check.
History
Date User Action Args
2014-12-25 17:17:05r.david.murraylinkissue23113 superseder
2014-08-10 12:37:48ncoghlansetmessages: + msg225139
2014-08-10 09:57:04djcsetmessages: + msg225135
2014-08-10 08:21:45Arfreversetstatus: open -> closed
resolution: fixed
messages: + msg225127

stage: resolved
2014-08-10 02:40:02python-devsetmessages: + msg225121
2014-08-09 23:58:18ncoghlansetmessages: + msg225120
2014-08-09 18:11:15djcsetmessages: + msg225107
2014-08-05 01:27:44ncoghlansetmessages: + msg224792
2014-08-04 23:39:32Arfreversetstatus: closed -> open

assignee: djc

nosy: + Arfrever
messages: + msg224787
resolution: fixed -> (no value)
stage: resolved -> (no value)
2014-07-30 13:17:09berker.peksagsetstage: patch review -> resolved
2014-07-29 15:27:11djcsetstatus: open -> closed
resolution: fixed
messages: + msg224229
2014-07-29 15:25:59python-devsetnosy: + python-dev
messages: + msg224228
2014-07-25 15:19:50vstinnersetnosy: + vstinner
2014-07-24 08:02:48djcsetmessages: + msg223816
2014-07-24 08:01:38djcsetfiles: + bug21591.patch
keywords: + patch
messages: + msg223814

stage: needs patch -> patch review
2014-07-23 13:15:53djcsetnosy: + djc
2014-07-22 21:25:41Neil Mullersetnosy: + Neil Muller
messages: + msg223701
2014-07-22 18:30:09gvanrossumsetnosy: + gvanrossum
messages: + msg223680
2014-05-30 19:33:50terry.reedysetnosy: + terry.reedy, brett.cannon, ncoghlan, benjamin.peterson, georg.brandl

messages: + msg219417
stage: needs patch
2014-05-28 08:47:59rjordenscreate