bpo-39198: Ensure logging global lock is released on exception in isEnabledFor

[DerekTBrown]

This is a relatively small change which makes it easier to reason about the global _acquireLock() behavior inside of isEnabledFor:

1. Other callsites call _releaseLock inside of a finally block, ensuring that the lock is released even if exceptions are thrown (Example). This diff's primary goal is to ensure _releaseLock is called inside a finally block.
   1. This makes it easier to prove the correctness of isEnabledFor, because we no longer need to assert than no exceptions are thrown in order for the lock to be released.
   2. When using libraries like stopit, this ensures the lock is released even if exceptions are injected.
2. Nested try statements are stylistically bad. Instead, create a helper function to contain the uncached behavior of determining if a logger is enabled for a particular status.

https://bugs.python.org/issue39198

[the-knights-who-say-ni]

Hello, and thanks for your contribution!

I'm a bot set up to make sure that the project can legally accept this contribution by verifying everyone involved has signed the PSF contributor agreement (CLA).

Recognized GitHub username

We couldn't find a bugs.python.org (b.p.o) account corresponding to the following GitHub usernames:

@DerekTBrown

This might be simply due to a missing "GitHub Name" entry in one's b.p.o account settings. This is necessary for legal reasons before we can look at this contribution. Please follow the steps outlined in the CPython devguide to rectify this issue.

You can check yourself to see if the CLA has been received.

Thanks again for the contribution, we look forward to reviewing it!

[DerekTBrown]

I just signed CLA.

[csabella]

Hi @DerekTBrown, thank you for your contribution and for helping to improve CPython. Please open an issue on bugs.python.org and update the title of the PR with the ticket number. Trivial changes are for things like one word spelling changes and anything more than that should have a bug ticket. Thank you!

[DerekTBrown]

Thanks @csabella! I filed a BPO and created a news entry as well. Let me know if I need to make changes to the content in either of those places.

[bharel]

I feel like nesting a try won't actually pose an issue, it'll be faster and frankly enough more readable I believe.

[vsajip]

I would also prefer to not add the extra method but handle with a nested try, while ensuring that Gareth Rees' comment is also addressed.

[bedevere-bot]

A Python core developer has requested some changes be made to your pull request before we can consider merging it. If you could please address their requests along with any other requests in other reviews from core developers that would be appreciated.

Once you have made the requested changes, please leave a comment on this pull request containing the phrase I have made the requested changes; please review again. I will then notify any core developers who have left a review that you're ready for them to take another look at this pull request.

[DerekTBrown]

I have made the requested changes; please review again. Given comments, I made a simpler change and just wrapped setting the level in a try...finally block.

[bedevere-bot]

Thanks for making the requested changes!

@vsajip: please review the changes made to this pull request.

[miss-islington]

Thanks @DerekTBrown for the PR, and @vsajip for merging it 🌮🎉.. I'm working now to backport this PR to: 3.8.
🐍🍒⛏🤖

[bedevere-bot]

GH-17897 is a backport of this pull request to the 3.8 branch.

[miss-islington]

Thanks @DerekTBrown for the PR, and @vsajip for merging it 🌮🎉.. I'm working now to backport this PR to: 3.7.
🐍🍒⛏🤖

[bedevere-bot]

GH-17898 is a backport of this pull request to the 3.7 branch.