Added documentation and code examples for W0134 return-in-finally checker

[MariaMa-GitHub]

Motivation and Context

W0134 return-in-finally is a new check in Pylint which was added at the end of last semester, so it needed to be added to the PythonTA documentation. This pull request resolves the issue by providing documentation and examples for this checker.

Fixes #999.

Your Changes

Description:

• Added documentation for W0134 return-in-finally checker.
• Wrote a code example that raises the W0134 return-in-finally error.
• Provided a correction to the example code that demonstrates how to resolve the W0134 return-in-finally error.

Type of change (select all that apply):

• Documentation update (change that modifies or updates documentation only)

Testing

This pull request was tested using PythonTA with the code below.

import python_ta

python_ta.check_all()

The PythonTA report correctly showed that the W0134 (return-in-finally) error was raised.

Questions and Comments (if applicable)

I am not too sure how to classify the W0134 (return-in-finally) error. I chose to put it under "Improper Python usage" since I think that it does "indicate a misuse of variables, control flow, or other Python features in our code" and it is similar to other errors in the same section (such as Return outside function (E0104) and Unreachable (W0101)). However, when I ran PythonTA, it put the W0134 (return-in-finally) error under "Style and Convention", which also makes a bit of sense. Since I am not too sure how exactly this checker should be classified, I would like to ask under which section should it be put and in the future how should I decide if there are conflicts like this happening.

Checklist

• I have performed a self-review of my own code.
• I have verified that the CI tests have passed.
• I have reviewed the test coverage changes reported on Coveralls.

[coveralls]

Pull Request Test Coverage Report for Build 7688896823

Warning: This coverage report may be inaccurate.

We've detected an issue with your CI configuration that might affect the accuracy of this pull request's coverage report.
To ensure accuracy in future PRs, please see these guidelines.
A quick fix for this PR: rebase it; your next report should be accurate.

• 0 of 0 changed or added relevant lines in 0 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage decreased (-0.001%) to 96.891%

---

Totals
Change from base Build 7393327913:	-0.001%
Covered Lines:	3210
Relevant Lines:	3313

---

💛 - Coveralls

[david-yz-liu]

Good work, @MariaMa-GitHub! I left a few inline comments, and in addition to that have two overall comments:

1. Since this is your first pull request, please add your name to the list of contributors :)
2. In terms of decided where to put the error, it's a bit ad hoc right now. One guiding principle I use is to look for similar errors, or errors that are related to the same language features. In this case, you should look for errors related to exceptions (some recent ones are the "too broad exception" ones) and put this entry close to those. Don't worry about categorizing as "style" vs. "error" within PythonTA though, that's something we can revisit later.