Then i am closing #15221

We should also inform @ambv so it removes this from the main announcement of future releases.

FWIW I think that continue should never be allowed in a finally clause because it's tricky to implement, and simply should not be used in scripts (I feel the same about break and return in a finally, but that's not really possible to ban at this point). We had similar VM seg-faults in MicroPython for all these "unwinding jumps", see micropython/micropython@b735208 and micropython/micropython@e1fb03f for the fixes (for return and break respectively). Banning this syntax at the compile level would make things simpler.

@ncoghlan FYI we did discuss this topic at PyCon AU 2018

Actually this reversion does not solve the issue completely: https://bugs.python.org/issue37830#msg349513. So it does not make sense to do it.

The rationale of making life easier for interpreter implementors still applies though - the fact that try/finally can be used to suppress an exception is genuinely weird.

I have closed this issue because I do not see any sense in reverting changes for continue if there is the same issue with break. At least continue is not used in existing code, so it will not crash any program.

@serhiy-storchaka The request from MicroPython was to reconsider allowing this construct at all. The fact that break is broken in the same way is a solid argument that we should stop digging the hole deeper (and perhaps consider disallowing break as well). We're making work for other implementations for no good reason.

The request from MicroPython was to reconsider allowing this construct at all.

Probably here is not the right place to have such a discussion, but my aim was to raise the point that we also had issues with return/break/continue in a finally, and that I would support changing the language to disallow this combination of constructs.

return/break/continue in a finally suite will (silently) cancel any raised exception, which is unexpected behaviour and probably not what the writer of the Python code intended. At least there are other ways to write such code (without having return/break/continue in the finally) which has more explicit behaviour. I did a survey of the Python standard library and this pattern is rarely used. And where it is used it's easy to change it.

I would consider writing a PEP to disallow this construct, if there's interest.

@isidentical @dpgeorge A draft PEP for that would be a good next step. I'd be happy to take on the PEP sponsor role.

For continue, the proposal would be to not add support in Python 3.8, while for return and break, the proposal would be to deprecate in 3.9, emit a compilation warning in 3.10, and then disallow after that.

Ok, I'll draft a PEP.

PEP 601 was rejected (although I think it contains a reasonable seed).