Pylint is a static analysis tool for Python that inspects source code without running it. It enforces coding standards, flags suspicious constructs, and reports on design issues such as overly complex functions and duplicate code blocks across a project.

What is the difference between pylint and Ruff?

Pylint is a Python-based linter with deep semantic checks, including some inference about argument types and call validity. Ruff is a Rust-based linter that runs orders of magnitude faster and now implements a growing subset of pylint's rules with autofix support. Many pylint checks remain unique to pylint.

Can pylint fix code automatically?

No. Pylint reports issues but does not rewrite code. Tools like Ruff and Black handle automated fixes for the rules they cover, so projects that want autofix typically pair pylint with a formatter or migrate the overlapping checks to Ruff.

pylint: Python Static Code Analyzer

Q: Should I use pylint or Ruff?

Ruff is the better default for new projects: it bundles formatting, import sorting, and linting in a single fast tool. Pylint stays useful when its semantic checks (duplicate-code detection, cyclomatic complexity, design-rule enforcement) matter to your codebase, or when an existing `.pylintrc` and CI pipeline already depend on it.

by Tim Hopper

Type Checking

Pylint is a static analysis tool for Python. It parses source code without executing it and reports coding-standard violations, suspicious constructs, and design-level issues such as overly complex functions and duplicate code blocks.

When to use pylint

Pylint suits codebases that already depend on its semantic checks: duplicate-code detection across modules and design-rule enforcement that style-focused linters do not cover. Teams with an established .pylintrc and a CI pipeline tuned around its output keep a familiar tool backed by a long-running plugin ecosystem.

For new projects, Ruff implements a growing subset of pylint’s rules with autofix support and much faster runs. The Ruff and Pylint comparison covers the trade-offs side by side, and How to replace Black, isort, flake8, and pyupgrade with Ruff walks through consolidating an existing lint stack onto Ruff.

Key Features

Static analysis

Pylint inspects source code without executing it, flagging undefined names, unused variables, dangerous default arguments, suspicious comparisons, and many design-level issues. It performs limited type inference to catch wrong-argument and wrong-attribute errors that pure style linters miss; for full type checking, pair it with mypy or ty.

Configuration

Pylint reads configuration from a .pylintrc file, setup.cfg, or the [tool.pylint] table in pyproject.toml. Rules can be enabled or disabled globally, per file with directive comments, or per line with # pylint: disable=.

Plugins

A plugin system (pylint.checkers) lets teams add custom checkers. The pylint-pydantic and pylint-django plugins are common examples; Pylint itself ships with first-party support for some popular libraries.

Reports

Beyond per-file findings, pylint produces a numeric score, cyclomatic-complexity reports, and duplicate-code (R0801) detection across the project. The score and metrics are useful for tracking trends in CI but are not a substitute for reading the underlying findings.

Pros

Semantic checks (duplicate code and design rules) that style-only linters do not cover
Highly configurable per-rule and per-file
Long-running plugin ecosystem
Detailed, message-coded output (C0103, R0801, etc.)

Cons

Slower than Ruff by orders of magnitude on large codebases
No autofix
Default rule set produces many false positives without tuning

Learn More

Last updated on May 11, 2026

PyInstaller pyproject.toml

Please submit corrections and feedback...