[issue34705] Python 3.8 changes how returns through finally clauses are traced

[Serhiy Storchaka]

Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

This is a side effect of specific optimization. If the return value is constant, it is pushed on the stack after executing the finally code (see LOAD_CONST at offset 14 below). But other opcodes at this line (POP_BLOCK and CALL_FINALLY) are executed after executing the finally code. Thus it looks like the line 4 is executed twice, but actually different opcodes marked with the same line are executed before and after executing the finally code.

Disassembly of <code object return_from_finally at 0x7feff78897c0, file "<stdin>", line 1>:
  2           0 SETUP_FINALLY           16 (to 18)

  3           2 LOAD_GLOBAL              0 (print)
              4 LOAD_CONST               1 ('returning')
              6 CALL_FUNCTION            1
              8 POP_TOP

  4          10 POP_BLOCK
             12 CALL_FINALLY             4 (to 18)
             14 LOAD_CONST               2 (17)
             16 RETURN_VALUE

  6     >>   18 LOAD_GLOBAL              0 (print)
             20 LOAD_CONST               3 ('finally')
             22 CALL_FUNCTION            1
             24 POP_TOP
             26 END_FINALLY
             28 LOAD_CONST               0 (None)
             30 RETURN_VALUE

The benefit of this optimization is that it can make the stack smaller. This decreases the memory consumption of the Python function frame by one pointer and speeds up the Python function frame creation time (one pointer assignment less). It is tiny, but I think it is worth to keep it.

I don't know what is the right solution here.

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34705>
_______________________________________