Update checks for PEP 765 - return/break/continue in finally block

[cdce8p]

Description

Python 3.14 will emit SyntaxWarnings for return / break / continue inside finally blocks. Pylint has some checks for it already.

• return-in-finally
• continue-in-finally -> previously only emitted for Python <3.8 as error. This is now changed to a warning (similar to return-in-finally) and emitted for every Python version.

Added a new check for break-in-finally.

https://peps.python.org/pep-0765/

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 95.86%. Comparing base (fccbf98) to head (2971fe3).
⚠️ Report is 2 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main   #10480      +/-   ##
==========================================
- Coverage   95.86%   95.86%   -0.01%     
==========================================
  Files         176      176              
  Lines       19155    19154       -1     
==========================================
- Hits        18363    18362       -1     
  Misses        792      792              

Files with missing lines	Coverage Δ
pylint/checkers/base/basic_error_checker.py	95.41% <100.00%> (-0.03%)	⬇️

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[github-actions]

🤖 According to the primer, this change has no effect on the checked open source code. 🤖🎉

This comment was generated for commit 2971fe3

[Pierre-Sassoulas]

Thank you for working on this. It's strange to decrease the error level while this became a syntax error upstream (thus it could have been a warning before in pylint but now it should be an error ?). I'm a little confused by this. The old/current message in pylint feel not accurate before 3.14 which add to the confusion.

[cdce8p]

It's strange to decrease the error level while this became a syntax error upstream (thus it could have been a warning before in pylint but now it should be an error ?). I'm a little confused by this. The old/current message in pylint feel not accurate before 3.14 which add to the confusion.

I wouldn't think of it this way. Using continue in a finally block was originally a syntax error until 3.8 (I believe) at which point pylint also stopped emitting the error for it.

I've now repurposed it to warn for the new syntax warning. So it's more

Error -> disabled -> Warning

[Pierre-Sassoulas]

Are you sure it's going to be a SyntaxWarning ? In the PEP it's one or the other but it looked like a SyntaxError to me when parsing with python 3.14 in astroid.

(I searched for the release note and you're indeed right: https://docs.python.org/3.14/whatsnew/3.14.html#pep-765-disallow-return-break-continue-that-exit-a-finally-block. It was preventing all analysis of a file with a syntax error though (at least until recently maybe it changed ?).)

[cdce8p]

(I searched for the release note and you're indeed right: https://docs.python.org/3.14/whatsnew/3.14.html#pep-765-disallow-return-break-continue-that-exit-a-finally-block. It was preventing all analysis of a file with a syntax error though (at least until recently maybe it changed ?).)

That was because of our pytest config with filterwarnings set to error. Take a look at the changes in pyproject.toml here. They resolve most of the issues. I.e. we don't need to differentiate between versions because of return in finally, ... as we do in #10467 anymore.

Maybe this would even work for astroid. Haven't checked it yet.

[Pierre-Sassoulas]

Wow, okay then. I wonder how I missed that. Thank you for clarifying.

Maybe we want to make return-in-finally's verbiage consistent with the others ? (i.e. "'x' discouraged inside 'finally' clause" vs "'x' shadowed inside 'finally' clause ") ?

[cdce8p]

Maybe we want to make return-in-finally's verbiage consistent with the others ? (i.e. "'x' discouraged inside 'finally' clause" vs "'x' shadowed inside 'finally' clause ") ?

Decided against doing that as "shadowed inside finally clause" is technically better IMO. The PEP even separates the two cases return and break / continue. The latter two just don't re-raise exceptions whereas return would overwrite any return inside the try block as well.
https://peps.python.org/pep-0765/#motivation

[Pierre-Sassoulas]

Great PR !