Arfrever Frehtes Taifersar Arahesis added the comment:
test_excinfo_no_python_sourcecode of py now passes.
--
resolution: - fixed
stage: - resolved
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21591
Dirkjan Ochtman added the comment:
Thanks, Benjamin, for reverting the run-time bits.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21591
___
Nick Coghlan added the comment:
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.
--
___
Python tracker rep...@bugs.python.org
Dirkjan Ochtman added the comment:
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.
--
Nick Coghlan added the comment:
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
Roundup Robot added the comment:
New changeset 0e9b023078e6 by Benjamin Peterson in branch '2.7':
restore runtime exec test (#21591)
http://hg.python.org/cpython/rev/0e9b023078e6
--
___
Python tracker rep...@bugs.python.org
Arfrever Frehtes Taifersar Arahesis added the comment:
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
Nick Coghlan added the comment:
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
Changes by Berker Peksag berker.pek...@gmail.com:
--
stage: patch review - resolved
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21591
___
___
Roundup Robot added the comment:
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
Dirkjan Ochtman added the comment:
Thanks to Victor Stinner for the review!
--
resolution: - fixed
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21591
___
Changes by STINNER Victor victor.stin...@gmail.com:
--
nosy: +haypo
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21591
___
___
Python-bugs-list
Dirkjan Ochtman added the comment:
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).
Dirkjan Ochtman added the comment:
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.
--
___
Python tracker rep...@bugs.python.org
Changes by Dirkjan Ochtman dirk...@ochtman.nl:
--
nosy: +djc
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21591
___
___
Python-bugs-list mailing
Guido van Rossum added the comment:
This does appear to be a bug. Please research the C code that originates the
error message -- there's probably a simple logic mistake.
--
nosy: +gvanrossum
___
Python tracker rep...@bugs.python.org
Neil Muller added the comment:
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;
}
Terry J. Reedy added the comment:
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:
New submission from Robert Jordens:
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
---
19 matches
Mail list logo