New submission from Greg Price:
In a multi-line list comprehension (or dict or set comprehension), the code for
the main expression of the comprehension is wrongly attributed to the *last*
line of the comprehension, which might be several lines later.
This makes for quite baffling tracebacks when an exception occurs -- for
example this program:
```
def f():
return [j
for i in range(3)
if i]
f()
```
produces (with CPython from current `default`):
```
Traceback (most recent call last):
File "foo.py", line 15, in <module>
f()
File "foo.py", line 3, in f
for i in range(3)
File "foo.py", line 4, in <listcomp>
if i]
NameError: name 'j' is not defined
```
showing the line `if i]`, which has nothing to do with the error and gives very
little hint as to where the exception is being raised.
Disassembly confirms that the line numbers on the code object are wrong:
```
2 0 BUILD_LIST 0
3 LOAD_FAST 0 (.0)
>> 6 FOR_ITER 18 (to 27)
3 9 STORE_FAST 1 (i)
4 12 LOAD_FAST 1 (i)
15 POP_JUMP_IF_FALSE 6
18 LOAD_GLOBAL 0 (j)
21 LIST_APPEND 2
24 JUMP_ABSOLUTE 6
>> 27 RETURN_VALUE
```
The `LOAD_GLOBAL` instruction for `j` is attributed to line 4, when it should
be line 2.
A similar issue affects multi-line function calls, which get attributed to a
line in the last argument. This is less often so seriously confusing because
the function called is right there as the next frame down on the stack, but
it's much more common and it makes the traceback look a little off -- I've
noticed this as a minor annoyance for years, before the more serious
comprehension issue got my attention.
Historically, line numbers were constrained to be wrong in these ways because
the line-number table `co_lnotab` on a code object required its line numbers to
increase monotonically -- and the code for the main expression of a
comprehension comes after all the `for` and `if` clauses, so it can't get a
line number earlier than theirs. Victor Stinner's recent work in
https://hg.python.org/cpython/rev/775b74e0e103 lifted that restriction in the
`co_lnotab` data structure, so it's now just a matter of actually entering the
correct line numbers there.
I have a draft patch to do this, attached here. It fixes the issue both for
comprehensions and function calls, and includes tests. Things I'd still like
to do before considering the patch ready:
* There are a couple of bits of logic that I knock out that can probably be
simplified further.
* While I'm looking at this, there are several other forms of expression and
statement that have or probably have similar issues, and I'll want to go and
review them too to either fix or determine that they're fine. The ones I've
thought of are included in the draft test file, either as actual tests (with
their current answers) or TODO comments for me to investigate.
Comments very welcome on the issue and my draft patch, and meanwhile I'll
continue with the further steps mentioned above.
Thanks to Benjamin Peterson for helping diagnose this issue with me when we ran
into a confusing traceback that ran through a comprehension.
----------
components: Interpreter Core
files: lines.diff
keywords: patch
messages: 260966
nosy: Greg Price
priority: normal
severity: normal
status: open
title: Wrong line number attributed to comprehension expressions
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6
Added file: http://bugs.python.org/file42042/lines.diff
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue26452>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
