# pylint: Python Static Code Analyzer

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](https://pydevtools.com/handbook/reference/ruff.md) implements a growing subset of pylint's rules with autofix support and much faster runs. The [Ruff and Pylint comparison](https://pydevtools.com/handbook/explanation/how-do-ruff-and-pylint-compare.md) covers the trade-offs side by side, and [How to replace Black, isort, flake8, and pyupgrade with Ruff](https://pydevtools.com/handbook/how-to/how-to-replace-black-isort-flake8-pyupgrade-with-ruff.md) 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](https://pydevtools.com/handbook/reference/mypy.md) or [ty](https://pydevtools.com/handbook/reference/ty.md).

### Configuration

Pylint reads configuration from a `.pylintrc` file, `setup.cfg`, or the `[tool.pylint]` table in [pyproject.toml](https://pydevtools.com/handbook/reference/pyproject.toml.md). 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](https://github.com/fcfangcc/pylint-pydantic) and [pylint-django](https://github.com/PyCQA/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](https://pydevtools.com/handbook/reference/ruff.md) by orders of magnitude on large codebases
- No autofix
- Default rule set produces many false positives without tuning

## Learn More

- [How do Ruff and Pylint compare?](https://pydevtools.com/handbook/explanation/how-do-ruff-and-pylint-compare.md)
- [How to replace Black, isort, flake8, and pyupgrade with Ruff](https://pydevtools.com/handbook/how-to/how-to-replace-black-isort-flake8-pyupgrade-with-ruff.md)
- [Set up Ruff for formatting and checking your code](https://pydevtools.com/handbook/tutorial/set-up-ruff-for-formatting-and-checking-your-code.md) (Tutorial)
- [Pylint documentation](https://pylint.readthedocs.io/)
- [Pylint on GitHub](https://github.com/pylint-dev/pylint)
- [Pylint message reference](https://pylint.readthedocs.io/en/latest/user_guide/messages/index.html)