Serhiy Storchaka added the comment:
I like the idea. I have not make faultfinding review yet, but one thing is
questionable to me.
Is it necessary to get rid of the END_FINALLY opcode?
Currently Python code
try:
stmt1
finally:
stmt2
is compiled to:
SETUP_FINALLY L1
// stmt1
POP_BLOCK
LOAD_CONST None
L1: // stmt2
END_FINALLY
With the patch it is compiled to:
SETUP_FINALLY L1
// stmt1
POP_BLOCK
// stmt2
JUMP_ABSOLUTE L2
L1: // stmt2
RERAISE
L2:
Finally body is duplicated. In case of large finally body this increases the
size of the bytecode. Line numbers are duplicated in disassembly listing, this
is confused. And I afraid that due to increasing the size of the bytecode, some
relative jumps can became too long.
If it is absolutely necessary to remove the END_FINALLY opcode, I suggest to
generate following bytecode:
SETUP_FINALLY L1
// stmt1
POP_BLOCK
LOAD_CONST None
L1: // stmt2
POP_JUMP_IF_FALSE L2
RERAISE
L2:
But it looks to me that special END_FINALLY opcode which combines
POP_JUMP_IF_FALSE/RERAISE would be better for performance and compiled code
size.
----------
components: +Interpreter Core
stage: -> patch review
type: -> enhancement
versions: +Python 3.5
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue17611>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
