Alexander Belopolsky <belopol...@users.sourceforge.net> added the comment:
> Is it really *interesting* to trace separate parts of list
> comprehensions like this?
It may or may not be useful for tracing code in the wild, but it helps to
isolate the causes of count mismatches.
I am attaching a file, x.py, that shows differing behavior for 3.1 and 3.2 and
with and without computed gotos in each version.
The traced code is
2 def f():
3 return [i
4 for i
5 in range(10)]
and the script prints the disassembly of f including the listcomp object.
The results are (s/g - with/without computed gotos):
3.1s: {('x.py', 3): 2, ('x.py', 5): 1}
3.1g: {('x.py', 4): 10, ('x.py', 3): 2, ('x.py', 5): 1}
3.2s: {('x.py', 3): 12, ('x.py', 5): 1}
3.2g: {('x.py', 4): 10, ('x.py', 3): 12, ('x.py', 5): 1}
Note that the bytecode is the same in all cases:
3 0 LOAD_CONST 1 (<code object <listcomp> at
0x1005250b8, file "x.py", line 3>)
3 MAKE_FUNCTION 0
5 6 LOAD_GLOBAL 0 (range)
9 LOAD_CONST 2 (10)
12 CALL_FUNCTION 1
15 GET_ITER
16 CALL_FUNCTION 1
19 RETURN_VALUE
listcomp:
3 0 BUILD_LIST 0
3 LOAD_FAST 0 (.0)
>> 6 FOR_ITER 12 (to 21)
4 9 STORE_FAST 1 (i)
12 LOAD_FAST 1 (i)
15 LIST_APPEND 2
18 JUMP_ABSOLUTE 6
>> 21 RETURN_VALUE
----------
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue9315>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
