Mark Dickinson added the comment:
> I don't see what the problem is here. People just don't write code like that.
Yes, agreed; as I said in the original post, I'm not expecting any action, but
the effect did seem interesting enough to be worth noting in an issue (if only
so that it can be re
Mark Dickinson added the comment:
> And there may be more than one return/break/continue statement in the try
> block. It increases the base of the degree.
Ah, interesting. My understanding was that that can't happen, but I'll double
check. In the control flow, all 'return' statements that l
Mark Shannon added the comment:
I don't see what the problem is here.
People just don't write code like that, at least not if they do code review ;)
And even, in the *extremely* rare case that they do, the code executes
correctly and reasonably quickly. It just uses a bit of extra memory.
--
Serhiy Storchaka added the comment:
And there may be more than one return/break/continue statement in the try
block. It increases the base of the degree.
At least for "return" we perhaps can merge different cases. But it would
complicate the compiler and cannot help in other cases.
Mark Dickinson added the comment:
For extra fun, you can add `break` and `continue` paths into the mix to get a
5-fold instead of 3-fold code size increase per level of nesting. It's still
contrived code, though.
Example where do_cleanup() ends up with 5**4 = 625 paths:
def f():
New submission from Mark Dickinson :
tl;dr - contrived (but relatively short) code involving nested try/finally
blocks can produce disproportionately large bytecode. I'm not expecting or
suggesting any action here, but the situation seemed at least worth noting.
Feel free to close this issue
