homepage

> 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