Increase pylint fail-under threshold

[devendra1973]

Update [tool.pylint.messages_control].fail-under from 6.5 to 8.5 as part of improving the repo's pylint score.

Closes #867.

Summary by CodeRabbit

Release Notes

No user-facing changes. This release contains internal development configuration updates to code quality standards.

_{✏️ Tip: You can customize this high-level summary in your review settings.}

[coderabbitai]

Walkthrough

Updated pylint configuration in pyproject.toml to raise the fail-under threshold from 6.5 to 8.5 and expanded the disable list to include four additional lint rules: broad-exception-caught, too-few-public-methods, logging-not-lazy, and logging-fstring-interpolation.

Changes

Cohort / File(s)	Summary
Pylint Configuration pyproject.toml	Increased fail-under threshold from 6.5 to 8.5 under [tool.pylint.messages_control]. Extended the disable list with four new rules: "broad-exception-caught", "too-few-public-methods", "logging-not-lazy", and "logging-fstring-interpolation".

Estimated code review effort

🎯 1 (Trivial) | ⏱️ ~3 minutes

Pre-merge checks and finishing touches

❌ Failed checks (1 warning, 1 inconclusive)

Check name	Status	Explanation	Resolution
Out of Scope Changes check	⚠️ Warning	The addition of pylint disable rules goes beyond the stated requirement to simply increase fail-under to 8.5; these changes may mask code quality issues rather than improve them.	Either document why these disable rules are necessary to meet the 8.5 score, or remove them and address the underlying lint violations directly as indicated in issue #867.
Linked Issues check	❓ Inconclusive	The PR implements the primary requirement from issue #867 by updating fail-under to 8.5, but also added pylint disable rules not mentioned in the issue requirements.	Clarify whether the additional pylint disable rules (broad-exception-caught, too-few-public-methods, logging-not-lazy, logging-fstring-interpolation) are necessary to achieve the 8.5 score target or if they represent incomplete implementation.

✅ Passed checks (3 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title accurately reflects the main change in the changeset: increasing the pylint fail-under threshold from 6.5 to 8.5.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

✨ Finishing touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment

---

📜 Recent review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

Disabled knowledge base sources:

• Linear integration is disabled by default for public repositories

You can enable these sources in your CodeRabbit configuration.

📥 Commits

Reviewing files that changed from the base of the PR and between 9ab3cd3 and 2b84fb8.

📒 Files selected for processing (1)

• pyproject.toml (1 hunks)

🔇 Additional comments (1)

pyproject.toml (1)

287-297: The review comment is based on a factual misreading of the changes.

The four disabled rules (broad-exception-caught, too-few-public-methods, logging-not-lazy, logging-fstring-interpolation) were already disabled in the previous version of pyproject.toml. The diff shows that only one change was made in this commit: raising fail-under from 6.5 to 8.5. No new rules were added to the disable list.

The concern that rules were disabled as a workaround to meet the higher threshold is unfounded. The developer is legitimately increasing the code quality threshold without introducing new rule suppressions.

Likely an incorrect or invalid review comment.

Tip

📝 Customizable high-level summaries are now available in beta!

You can now customize how CodeRabbit generates the high-level summary in your pull requests — including its content, structure, tone, and formatting.

• Provide your own instructions using the high_level_summary_instructions setting.
• Format the summary however you like (bullet lists, tables, multi-section layouts, contributor stats, etc.).
• Use high_level_summary_in_walkthrough to move the summary from the description to the walkthrough section.

Example instruction:

"Divide the high-level summary into five sections:

1. 📝 Description — Summarize the main change in 50–60 words, explaining what was done.
2. 📓 References — List relevant issues, discussions, documentation, or related PRs.
3. 📦 Dependencies & Requirements — Mention any new/updated dependencies, environment variable changes, or configuration updates.
4. 📊 Contributor Summary — Include a Markdown table showing contributions:
   | Contributor | Lines Added | Lines Removed | Files Changed |
5. ✔️ Additional Notes — Add any extra reviewer context.
   Keep each section concise (under 200 words) and use bullet or numbered lists for clarity."

Note: This feature is currently in beta for Pro-tier users, and pricing will be announced later.

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}