[skdas20]

Type of Changes

	Type
✓	🐛 Bug fix

Description

superfluous-parens (C0325) gave a blanket pass to any parenthesised expression containing and/or, so conditions like if (a is None and a is not None): were never reported — even though the same expression without boolean operators (e.g. if (a == 5): or K = ("a" + "b")) is reported. This makes the and/or exemption narrower, keeping it only where the parentheses are genuinely required:

• after not — not (a and b) parses differently without parens;
• when the parenthesised expression is an operand of a following binary operator — e.g. (a or b) in c.

Parentheses that wrap the entire statement expression (if (a and b):, while (a or b):) are now reported. Multiline conditions are untouched (the existing NL bail-out), as are partial groupings like if (a and b) or c:.

This follows the same "narrow the historical blanket pass" approach as #11081 did for in, which left this case explicitly out of scope. Existing functional suite passes (900 tests), and running the updated check over pylint's own source produces no new hits (the three pre-existing C0325 hits on main are unchanged by this PR).

Note: #10084 is assigned to @ranadheerg — I asked on the issue whether they're still working on it before opening this; happy to close this in favor of their PR if they are.

Closes #10084

[skdas20]

Assignment question on #10084 is resolved — @ranadheerg has handed it over (#10084 (comment)), so this is no longer stepping on anyone's work and is ready for review whenever someone has a moment.

Recapping the state since it's been open a little while: superfluous-parens gave a blanket pass to any parenthesised expression containing and/or, so if (a is None and a is not None): was never reported even though if (a == 5): is. This narrows that exemption to the cases where the parentheses are genuinely required — after not, and where the parenthesised expression is an operand of a following binary operator — following the same approach #11081 used for in.

All 900 functional tests pass, and running the updated check over pylint's own source yields no new hits beyond the three already present on main. The primer will surface new messages on external code, which is expected for a false-negative fix — happy to walk through any that look wrong.