This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author belopolsky
Recipients alexandre.vassalotti, amaury.forgeotdarc, belopolsky, collinwinter, eli.bendersky, ezio.melotti, flox, georg.brandl, jyasskin, pitrou, rhettinger, teresap989, terry.reedy
Date 2010-09-15.21:22:59
SpamBayes Score 1.9221947e-08
Marked as misclassified No
Message-id <1284585781.8.0.0490639400631.issue9866@psf.upfronthosting.co.za>
In-reply-to
Content
Attached test script, tracetest.py, prints disassembly followed by a trace of the following function:


1  def f():
2      return [i
3              for i
4              in range(2)]


With default configuration, the output is


  2           0 LOAD_CONST               1 (<code object <listcomp> at 0x100484e00, file "tracetest.py", line 2>) 
              3 MAKE_FUNCTION            0 

  4           6 LOAD_GLOBAL              0 (range) 
              9 LOAD_CONST               2 (2) 
             12 CALL_FUNCTION            1 
             15 GET_ITER             
             16 CALL_FUNCTION            1 
             19 RETURN_VALUE         
listcomp:
  2           0 BUILD_LIST               0 
              3 LOAD_FAST                0 (.0) 
        >>    6 FOR_ITER                12 (to 21) 

  3           9 STORE_FAST               1 (i) 
             12 LOAD_FAST                1 (i) 
             15 LIST_APPEND              2 
             18 JUMP_ABSOLUTE            6 
        >>   21 RETURN_VALUE         
['2 0 LOAD_CONST', '4 6 LOAD_GLOBAL', '2 0 BUILD_LIST', '3 9 STORE_FAST', '2 6 FOR_ITER', '3 9 STORE_FAST', '2 6 FOR_ITER']

but with configuration using --without-computed-gotos option, the disassembly is the same, but the trace is different:


['2 0 LOAD_CONST', '4 6 LOAD_GLOBAL', '2 0 BUILD_LIST', '2 6 FOR_ITER', '2 6 FOR_ITER']

This behavior changed between 3.1 and 3.2 (likely in r74132), but it is inconsistent in both versions.  Since r74132 changes were not backported to 3.1, I am classifying this as 3.2 only even though the problem is present in 3.1 as well.

See also issues #6042 and #9315.
History
Date User Action Args
2010-09-15 21:23:01belopolskysetrecipients: + belopolsky, georg.brandl, collinwinter, rhettinger, terry.reedy, amaury.forgeotdarc, pitrou, alexandre.vassalotti, jyasskin, ezio.melotti, eli.bendersky, flox, teresap989
2010-09-15 21:23:01belopolskysetmessageid: <1284585781.8.0.0490639400631.issue9866@psf.upfronthosting.co.za>
2010-09-15 21:22:59belopolskylinkissue9866 messages
2010-09-15 21:22:59belopolskycreate