Neil Schemenauer <nas-pyt...@arctrix.com> added the comment: After studying the patch and doing some reading, I prefer the finally-block duplication approach as well. Java does it that way as well and it works for them. It would be be interesting to compile a large body of packages and see what the increase in bytecode size actually is with the duplication. My gut feeling is that it will not be a big deal.
There is a bug with the PR regarding the final bodies. Exits from the final body cause the whole fblock stack to unwind, not just the blocks enclosing the final body. Unwind looks at 'c' to get the fblock stack. I think we need to allocate fblockinfo on the C stack and then use a back pointer to enclosing block. When you get into a final body that creates its own fblockinfo (e.g. a try/except inside the finally), the current code doesn't work. The fact that the whole test suite passes with these issues tells me that the amount of stuff happening in final bodies must be pretty simple in most code. I spent a good part of Sunday trying to understand how the PR works. It seems to me that the ceval/bytecode changes are pretty solid. The compiler needs some bug fixes. Further optimisations could be done at a later time. I'm curious to see Serhiy's approach though. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue17611> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
