# Selected every rule the Python linter has as an error, working through 1,815 findings to reach zero, with each of the few exemptions carrying a written reason and two of them backed by a checker instead of a comment.

2025

**Situation.** Most projects pick a comfortable subset of their linter's rules, and the subset is chosen by whichever rules were quiet on the day it was configured. That makes the configuration a record of the code's existing habits rather than a standard the code is held to, and every rule left off is a class of defect nobody will ever be told about.

**Task.** The default had to be inverted — every rule the tool implements enabled as an error — and the resulting backlog worked to zero rather than negotiated down by turning rules back off.

**Action.** Selecting the complete rule set produced 1,815 findings on first run. They were worked through by category rather than by file, because the categories tell you something: unused arguments and shadowed builtins are noise, but the security category, the mutable‑default category and the exception‑handling category each pointed at real behaviour. Genuine incompatibilities exist — a formatter and a linter can disagree about the same line, and a few rules contradict the project's own deliberate choices — and each of the small number of exemptions carries a written reason at the point of exemption saying what the rule wanted and why this code does otherwise. Two of them go further and are backed by a check rather than a comment, so the exemption cannot quietly widen: the rule is off, and a test asserts the specific property the rule would have enforced. Type checking runs in strict mode alongside it, which is a separate and harder standard, and it is the one that caught defects the linter could not see because they are about what a value is rather than how it is written.

**Result.** The linter runs at full strength with zero findings, and every deviation is documented at the line where it is taken. The cost is real and worth naming: the strictest setting produces findings that are genuinely not worth acting on, and someone has to make that judgement 1,815 times rather than once.

---

- Role: Python Engineer
- Categories: [DevOps](https://engineer.company/categories/devops/), [Automation & CI/CD](https://engineer.company/categories/automation/), [Testing & QA](https://engineer.company/categories/testing/), [Python](https://engineer.company/categories/python/), [Documentation](https://engineer.company/categories/documentation/)
- Services: [Backend & API Development](https://engineer.company/services/backend-development/), [DevOps & CI/CD Automation](https://engineer.company/services/devops-cicd/), [Technical Leadership & Consulting](https://engineer.company/services/technical-leadership/)

<https://engineer.company/portfolio/enabled-every-python-linter-rule-as-an-error-147/>
