# PEP 765: Disallow return/break/continue that exit a finally block **URL:** \ **Category:** PEPs\ **Created:** [November 16, 2024, 10:28am UTC](https://discuss.python.org/t/pep-765-disallow-return-break-continue-that-exit-a-finally-block/71348 "2024-11-16T10:28:23Z")\ **Posts on this page:** 1\ **Showing post:** 4
**Author:** ![guido](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/guido/32/21_2.png) [@guido](https://discuss.python.org/u/guido)\ **Post date:** [November 16, 2024, 4:08pm UTC](https://discuss.python.org/t/pep-765-disallow-return-break-continue-that-exit-a-finally-block/71348/4 "2024-11-16T16:08:59Z")
This is an excellent piece of research and perhaps we should do more PEPs based on such investigations. That said, I am personally sad to see this syntactic corner case disappear. To me, when I designed it, the semantics were always completely logical. (E.g., if you have two nested try/finally blocks, if the inner finally returns, the outer finally still gets to run, and can even override the control flow!) The idea was that Python has many constructs, and they can be combined in “orthogonal” ways. (Something I got from Algol-68’s stated philosophy.) Other languages with finally seem to do it the same way (I’ve only tried TypeScript). But I understand that in this case users pay a price for that orthogonality, and I have given control of the language to the steering council, whom I totally trust. Next you might want to have a look at `for a[i] in ...: ...` or perhaps even the mysterious `else` clause on loops, which is so often misunderstood. --- _[View the full topic](https://discuss.python.org/t/pep-765-disallow-return-break-continue-that-exit-a-finally-block/71348)._