# PEP 765: Disallow return/break/continue that exit a finally block

**URL:** <https://discuss.python.org/t/pep-765-disallow-return-break-continue-that-exit-a-finally-block/71348>\
**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:** 146

<div class="post-metadata">

**Author:** ![Liz](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/liz/32/15021_2.png) [@Liz](https://discuss.python.org/u/Liz)\
**Post date:** [August 30, 2025, 4:57pm UTC](https://discuss.python.org/t/pep-765-disallow-return-break-continue-that-exit-a-finally-block/71348/146 "2025-08-30T16:57:21Z")

</div>

> [@Liz](#):
>
> I don’t like this change. Either make it an error or don’t make it a warning. This halfway-inbetween stance is targeting a small number of users and telling them they are wrong, but without the conviction to actually make it an error, and instead doing it in a way that turns it into “lets annoy your users to shame you into changing it”

This turned out more accurate than I could have ever guessed at the time. I didnt know that syntax warnings werent filtered properly, that uv doesn’t precompile by default, and that in spite of that and that these were decisions that were supposed to limit the disruptiveness, that when they did not function as intended that people would keep defending tossing a linter rule into the language without a plan to make it an error.

This is effectively more disruptive than traditional deprecation for the few affected projects.

> [@iritkatriel](#):
>
> > [@guido](#):
> >
> > But in this case the decision was made _not_ to deprecate the questionable feature
> 
> This is not my understanding. The intention is to remove the feature from the language (to signal that it should not be used). It should be a `SyntaxError`, it’s not only because that would be disruptive for a small number of cases where people think that their use case is legitimate and not buggy (although it reads like a bug). The concession of using a Warning rather than Error didn’t work because people use -We so Warnings are Errors. And, evidently, it sent the unintended message that this is not a serious issue, since we didn’t say when it becomes an Error.

> CPython will emit a `SyntaxWarning` in version 3.14, and we leave it open whether, and when, this will become a `SyntaxError`

The PEP never committed to making it an error, which to me feels like this was just a way to do an end run around normal deprecation since you are now claiming that was always the intent for it to later be an error.

@hugovk the article there covers only the simplest case of try/finally. Nobody using it correctly has an issue with figuring out the right way to rewrite this, it’s the fact that working code has to be rewritten with no prior warning for what is amounts to a linter rule because it is impacting downstream code that is the problem. The warning breaks CI use of warning as errors immediately because this change was made without anyone verifying that warning filters would work (they don’t for this)

cases with nested try/finally while supressing errors require significantly more changes to properly retain the intened behavior, as outer finally blocks run even after returning in an inner one. This is a rather natural way to ensure ordered cleanup of things that must not fail to cleanup, and some libraries do intentionally suppress certain errors that their users wouldn’t be able to do anything about.

---

_[View the full topic](https://discuss.python.org/t/pep-765-disallow-return-break-continue-that-exit-a-finally-block/71348)._