Antoine Pitrou added the comment:
So, the approach of duplicating finally blocks tends to lead to a non-trivial
bytecode increase. There is even a potential combinatorial explosion with
nested "try..finally" block:
def f():
try:
...
finally:
try:
...
finally:
# etc.
Such a chain of N nested "finally"s will emit O(2**N) opcodes.
I'm not sure it's a pratical concern but I find it is detrimental to the
readibility of bytecode (which is a nice thing to have when doing low-level
debugging or tweaking). I think we can massage the PR to remove the "finally"
block duplication while keeping the predictable stack effect.
----------
_______________________________________
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
