Serhiy Storchaka <storchaka+cpyt...@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 <rep...@bugs.python.org>
<https://bugs.python.org/issue34705>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
