> 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