This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author Mark.Shannon
Recipients Demur Rumed, Mark.Shannon, benjamin.peterson, christian.heimes, mark.dickinson, nascheme, ncoghlan, pitrou, rhettinger, serhiy.storchaka, trent
Date 2017-12-29.16:45:55
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1514565955.87.0.213398074469.issue17611@psf.upfronthosting.co.za>
In-reply-to
Content
When I said "significant", I meant from a statistically, not as a judgement meaning "useful" or "worthwhile". The code duplication approach is significantly faster in the tests. Whether the small speed difference is worth worrying about is a different matter.

Also, the comparisons were with each other, not the current interpreter. Both approaches are better than the current implementation.

One point I didn't cover is jumping to a new line in the debugger.
Implementing that reliably for finally blocks with code duplication is tricky and would mean adding a number of marker bytecodes.
Which is a big point in favour of the JSR style.

If we are going to use the JSR approach, we should do it properly. 
PR 5006 still has elements of the current design such as the overly complex END_FINALLY, WITH_CLEANUP_START and WITH_CLEANUP_FINISH bytecodes. None of those should be necessary.
History
Date User Action Args
2017-12-29 16:45:55Mark.Shannonsetrecipients: + Mark.Shannon, nascheme, rhettinger, mark.dickinson, ncoghlan, pitrou, christian.heimes, benjamin.peterson, trent, serhiy.storchaka, Demur Rumed
2017-12-29 16:45:55Mark.Shannonsetmessageid: <1514565955.87.0.213398074469.issue17611@psf.upfronthosting.co.za>
2017-12-29 16:45:55Mark.Shannonlinkissue17611 messages
2017-12-29 16:45:55Mark.Shannoncreate