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 serhiy.storchaka
Recipients Demur Rumed, Mark.Shannon, benjamin.peterson, christian.heimes, mark.dickinson, nascheme, ncoghlan, pitrou, rhettinger, serhiy.storchaka, trent
Date 2017-12-04.12:25:34
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
I started on Antoine's PR and work on different approach ( which don't duplicate the code for continue/break/return. Instead it uses some kind of subroutines. END_FINALLY expects the one of three cases:

1. NULL (or None). Normal execution thread in try/finally. Continue from the instruction following END_FINALLY.

2. An integer. This is an address of returning. Continue from the specified address.

3. An exception (6 items). Raises the specified exception.

WITH_CLEANUP_FINISH behaves similarly.

The statements continue/break/return insert the instruction CALL_FINALLY which pushes the address of the following instruction on the stack and jumps to the start of the finally (or with cleanup) block. There can be several CALL_FINALLY instructions if you need to execute several finally blocks. At the jump instruction is inserted for continue and break, and RETURN_VALUE for return.

Currently I'm trying to simplify the code.
Date User Action Args
2017-12-04 12:25:35serhiy.storchakasetrecipients: + serhiy.storchaka, nascheme, rhettinger, mark.dickinson, ncoghlan, pitrou, christian.heimes, benjamin.peterson, trent, Mark.Shannon, Demur Rumed
2017-12-04 12:25:34serhiy.storchakasetmessageid: <>
2017-12-04 12:25:34serhiy.storchakalinkissue17611 messages
2017-12-04 12:25:34serhiy.storchakacreate