Python lint: Ruff rules for pylint and code complexity

[cclauss]

Add ruff rules for Pylint and McCabe cyclomatic code complexity.

• https://docs.astral.sh/ruff/rules/#pylint-pl
• https://docs.astral.sh/ruff/rules/#mccabe-c90

% ruff check --select=C90,PL --statistics | sort -k2

 5	C901   	[ ] complex-structure
 1	PLC0414	[ ] useless-import-alias
19	PLR0402	[*] manual-from-import
 1	PLR0911	[ ] too-many-return-statements
 1	PLR0912	[ ] too-many-branches
 5	PLR0913	[ ] too-many-arguments
 1	PLR0915	[ ] too-many-statements
26	PLR2004	[ ] magic-value-comparison
 1	PLW1510	[*] subprocess-run-without-check
[*] 20 fixable with the `--fix` option (1 hidden fix can be enabled with the `--unsafe-fixes` option).
Found 60 errors.

Motivation and Context

Pylint checks for errors, enforces a coding standard, looks for code smells, and can suggest how code could be refactored.
McCabe detects functions with high complexity that are hard to understand and maintain.

The C90 and PLR091 rules enable the setting of upper limits on code complexity. If a contributor wants to raise these limits, that can lead to useful discussion in code reviews about why complexity needs to rise and maintainability needs to go down.

How Has This Been Tested?

Breaking Changes

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Documentation update

Checklist

• I have read the MCP Documentation
• My code follows the repository's style guidelines
• New and existing tests pass locally
• I have added appropriate error handling
• I have added or updated documentation as needed

Additional context

[ihrpr]

Thank you for contributing to Python SDK!

1. Please can you provide rationale for the specific numerical thresholds chosen
2. Is implementing both C90 and PL linting rules simultaneously necessary?
3. Please remove the widespread import style changes which aren't central to the linting goals

The subprocess check=False change is great, but should be submitted as a separate PR focused on that specific fix.

[cclauss]

Please read the git commit when reviewing pull requests.

Please can you provide rationale for the specific numerical thresholds chosen

The C90 and PLR091 rules enable the setting of upper limits on code complexity. If a contributor wants to raise these limits, that can lead to useful discussion in code reviews about why complexity needs to rise and maintainability needs to go down.

The current code complexity determines the values set in this PR, with comments showing the recommended values. To find complexity in the codebase, just lower any of these values by one and run ruff check. Failure to review and merge this pr has forced an increase in max-complexity, max-branches, max-returns, and max-statements. Putting C90 and PLR091 in the same PR makes sense because they both set upper limits on code complexity and maintainability.

- mccabe.max-complexity = 13  # Default is 10
- max-branches = 14    # Default is 12
- max-returns = 7      # Default is 6
- max-statements = 69  # Default is 50
+ mccabe.max-complexity = 24  # Default is 10
+ max-branches = 23    # Default is 12
+ max-returns = 13      # Default is 6
- max-statements = 99  # Default is 50
+ max-statements = 102  # Default is 50

I have the RUFF settings to ignore the pylint import rules PLC0414 and PLR0402.

[felixweinberger]

Apologies for the delay in coming back to this.

It would be great if we could address the issues introduced by the new lint rules instead of adding linter overrides.

Happy to come back to this quickly if you have the capacity to take a stab at this?

[felixweinberger]

While I'm not a fan of ignoring ruff rules, in this case I believe it is justified given we're actually sharpening our lint rules overall and simply making explicit what we were previously implicitly ignoring.

Therefore I think we should land this in the interest of managing growing complexity on the Python SDK.

I've also created an issue for our v2 release where ideally we'd get rid of all ignores here.

[felixweinberger]

"PLC0415" and "PLR0402" are newly added.

I'm assuming that's because we've added to the selection of tools above causing new lint errors to appear that we previously were ignoring by omission?

If so I'm OK with this trade-off in the short term to have a bit more manageable complexity.

[felixweinberger]

Not my favorite solution, but assuming the same thing applies as above - we have this code already, we were just ignoring it by omission.

PLW0603

Requested changes have been addressed

[felixweinberger]

@cclauss thank you for the contribution and apologies again for the delay!