Beyond ruff: Boa Restrictor is the new Python linter on the block

How opinionated tooling will save your day — or night

Ruff is here, we don’t need any new linters? Well, maybe we can sell you our latest package, the novel linter boa-restrictor, to you.

Photo by Jan Kopřiva on Unsplash

What’s a Linter, Anyway?

It’s a linter tool that automatically analyzes source code to detect potential issues like syntax errors, bugs, style inconsistencies, or patterns that might lead to poor maintainability. Think of it as that friend who lets you know your tag is sticking out — a little awkward in the moment, but you’ll appreciate it later.

The Linter Landscape: A Very Brief History

The Python linting world has evolved from the slow-but-comprehensive flake8 (with its myriad of plugins) to the blazingly fast ruff, which reimplemented virtually every flake8 and pylint extension in Rust. Ruff became the cool kid on the block, and its company Astral is even working on replacing mypy with their type checker, ty.

So why add another player to this already crowded field?

Opinionated by Design

Our answer comes in the form of Boa Restrictor, a custom Python linter that ships with (at the time of writing) 13 highly opinionated rules designed to catch issues that other linters miss. The tool supports both Python-only projects and Django-specific code (another 8 rules), with extensive opt-out mechanisms for teams that don’t agree with every rule.

What Makes Boa Restrictor Different?

Unlike formatters (which restructure your code) and type checkers (which verify type hints match), it focuses on enforcing coding standards that can prevent bugs before runtime. The tool includes rules like:

• No positional arguments allowed (PBR001): Functions must use keyword-only arguments for better readability
• Return type hints required (PBR002): If your function returns something, you’d better tell us what
• Dataclasses must use kw_only (PBR004): Prevents the chaos of positional arguments in data classes
• Services have one public method called “process” (PBR005): Enforces a consistent pattern for service classes

For Django developers, there are additional rules like prohibiting assertTrue and assertFalse in tests (preferring the more expressive assertIs) and avoiding imports of django.db in views and API layers.

The Philosophy: Opinionated Is the Point

We don’t shy away from the fact that these rules are highly opinionated. As the project claim states: “These rules are opinionated and not all of them might suit your current project. That’s by design. “

The idea is to provide extensive exclusion mechanisms — you can disable rules globally, per-file, or even per-line using # noqa comments — giving teams the flexibility to adopt what works for them.

Technical Details

Boa Restrictor works as a pre-commit hook and uses Python’s Abstract Syntax Tree (AST) to analyze code. While it won’t match ruff’s Rust-powered speed, my experiments show that performance is acceptable even for large projects. The tool boasts 100% test coverage and is fully open source, with complete documentation available.

Integration with ruff is straightforward — teams can configure ruff to ignore Boa Restrictor’s custom rule codes, allowing both tools to coexist peacefully in the same pipeline.

Why Build Yet Another Linter?

Our motivation comes from a familiar pain point: repeatedly discussing (and missing!) the same code quality issues in pull request after pull request. By codifying these concerns into an automated linter, they save time, energy, and avoid the interpersonal friction of nitpicking during code review.

We’ve made another interesting observation here: “People tend to complain about rules more in a PR than in the pipeline.” By making these standards explicit and automated, teams can focus code reviews on logic and architecture rather than style debates.

The Downsides (Yes, There Are Some)

Well, to be honest, Boa Restrictor is perfect for everyone. Some rules might not apply to your project, or you might simply disagree with them. Per-file exclusion rules can become non-trivial to manage, and yes, it’s yet another tool to maintain in your development stack.

But for teams that align with our philosophy — or who want to enforce their own opinionated standards — Boa Restrictor provides an easy-to-extend framework. We’ve noticed that adding a new rule typically takes less than two hours from concept to release.

What’s Next?

We’re is actively seeking feedback from the Python community. The team acknowledges that finding broadly applicable rules is challenging, and they’re eager to hear which rules resonate (or repel) developers in the wild.

At the DjangoCologne meetup, a participant suggested a feature that every repo can have custom rules, based on a Python class which then will be run on a per-project basis. That’s a very boa-esque idea and would be a great way of pushing the linter one level further.

Conclusion

Boa Restrictor isn’t trying to replace ruff or become the new standard linter. Instead, it fills a niche for teams that want to enforce specific coding patterns that other tools don’t cover. Whether you love or hate its opinionated stance, the project represents something important: giving development teams the power to codify their own standards rather than accepting one-size-fits-all solutions (at least in regards to us 😅).

For Python developers tired of having the same code quality conversations in every pull request, Boa Restrictor might just be the tool you need — even if you don’t realize it yet.

— — —

**Boa Restrictor is available now as an open-source package. Documentation, installation instructions, and the full list of rules can be found in the project repository. Ambient Digital encourages developers to try it out, provide feedback, and contribute to the project’s evolution.**