How to Use Pylint, ignore / disable checkers, and comparing pylint to flake8 & ruff

This inspiring guide dives deep into pylint: what it is, how to use it, when to silence checks, how pylint compares to flake8 and ruff, and practical tips to integrate it into your workflow (VS Code, GitHub Actions, Ubuntu 20.04). Ready to level up code quality? Let’s go.

Introduction to Pylint

What is Pylint?

Pylint is a full static analysis tool. It provides scoring for modules, enforces naming conventions, detects unused imports, identifies possible runtime errors, and integrates with many editors and pipelines. Many engineering teams use pylint as a gatekeeper for pull requests.

pylint 4.0.2

Pylint 4.0.2 represents one of the modern stable releases (check the official project page for the latest): pylint.org. In the 4.x series, the project modernized internal APIs, improved performance, and continued refining messages and plugin support. If you’re running an older version, consider upgrading for improved analysis speed and better compatibility with recent Python versions.

Características generales

• Scoring of modules to track quality over time
• Pluggable checkers and extensions to code editors
• Highly configurable (via .pylintrc)
• Support for type hints and modern Python constructs
• Rich message categories (convention, refactor, warning, error, fatal)

Checkers included

Pylint ships with a set of checkers and helper utilities. You’ll find checkers for:

• imports and unused symbols
• Naming conventions
• Type hints and annotations
• Refactor suggestions

Plus, there’s a plugin architecture so you can write custom checkers for domain-specific rules (e.g., enforce internal API use or certain architecture constraints).

How to use pylint?

Install pylint from pip or uv

pip install pylint
uv pip install pylint

Check the installed version:

pylint --version

Getting started and practical usage. Basic command-line usage:

# Run pylint on a single file
pylint my_module.py

# Run pylint on a package
pylint my_package/

Example output includes messages like:

my_module.py:1:0: C0114: Missing module docstring (missing-module-docstring)
my_module.py:10:4: W0612: Unused variable 'x' (unused-variable)

Create a configuration file to customize checks:

pylint --generate-rcfile > .pylintrc

Edit the .pylintrc to enable/disable specific messages, adjust naming rules, or set maximum line lengths.

Disabling Pylint

There are times you need to silence a message: perhaps a check is noisy for intentionally unconventional code. Pylint supports per-line and per-block disabling. Common patterns include:

• Inline disable for a single line: #pylint: disable=message-name
• Disable multiple messages: #pylint: disable=unused-variable,missing-docstring
• Disable for a block with pragmas or in .pylintrc to ignore categories globally

Example: use pylint ignore line or disable a specific rule inline:

def func():
    x = 1  # pylint: disable=unused-variable

Another example for a whole function:

# pylint: disable=too-many-branches
def complex_function(...):
    ...
# pylint: enable=too-many-branches

Note the alternative shorthand pylint: disable and many editors will colorize these comments. Use them sparingly—overusing pylint disable defeats the value of static analysis.

Practical examples: .pylintrc snippets

Minimal configuration to ignore specific checks globally:

[MESSAGES CONTROL]
disable=
    C0114,  # missing-module-docstring
    C0116,  # missing-function-docstring

Or selectively enable strict checks:

[MASTER]
# maximum number of characters on a single line.
max-line-length=88

Pylint extension for Visual Studio Code

For many engineers, integrating pylint into the editor streamlines development. Visual Studio Code supports pylint via its Python extension. To enable pylint in VS Code:

# In settings.json
{
  "python.linting.enabled": true,
  "python.linting.pylintEnabled": true,
  "python.linting.pylintArgs": ["--rcfile=./.pylintrc"]
}

Once configured, VS Code shows pylint messages inline, making it easy to fix issues before committing. If you prefer another linter like ruff or flake8, VS Code supports those too—pick the tooling mix that fits your team.

Bonus : Integrate Pylint into Github Actions

Automate pylint in CI with GitHub Actions. Here’s a simple workflow to run pylint on push and pull requests:

name: Lint

on: [push, pull_request]

jobs:
  pylint:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Set up Python
        uses: actions/setup-python@v4
        with:
          python-version: '3.11'
      - name: Install dependencies
        run: |
          python -m pip install --upgrade pip
          pip install pylint
      - name: Run pylint
        run: |
          pylint my_package/ || true

Tip: don’t fail the entire workflow on pylint during early adoption; use reporting and and gradual enforcement. Later, gate the pipeline strictly (remove the || true) once the codebase meets the target quality threshold.

What differentiates Pylint?

Compared to simpler linters, pylint aims for depth over speed. It performs more semantic checks (for example, detecting incorrect method signatures or wrong number of arguments in overridden methods). That added depth is a double-edged sword: pylint can be stricter and report more items you’ll want to manage with configuration or selective disable rules.

Advised linters alongside pylint

Many teams pair pylint with other tools for a complete pipeline:

• flake8 — lightweight style/pep8 enforcement; often used alongside pylint
• black — code formatter (opinionated) to remove formatting debates
• isort — import sorting
• ruff — ultra-fast linter/formatter that can replace or complement flake8 and some pylint checks

flake8 vs pylint

Short comparison:

• flake8: fast, minimal, plugin-based; focuses on style and simple static checks. Perfect for CI fast-fail stages.
• pylint: deeper static analysis, more messages, built-in scoring, more configuration overhead but more semantic checks.

Recommendation: use both in many workflows (flake8 for quick style checks, pylint for deeper analysis). If CI time is critical, you can trim pylint’s checks or run it in a scheduled job rather than every PR.

ruff vs pylint

ruff is a relatively new, very fast linter written in Rust. It aims to consolidate many tools (formatting, linting) into a single, fast executable. Ruff vs pylint often comes down to speed and coverage: ruff is blazing fast and covers many style rules, but pylint still leads for deep semantic checks and configurability. Some teams use ruff for pre-commit speed and pylint for periodic or PR-level deeper analysis.

When to use pylint, flake8, or ruff?

Practical guidance:

• If you want deep, semantic analysis and an overall quality score, choose pylint.
• If you want a lightweight, fast style checker emphasizing PEP8, choose flake8.
• If speed and consolidation (formatting + linting) are important, evaluate ruff vs pylint — ruff can replace many tools but may not yet match pylint’s deep semantic checks.

Why engineers love and sometimes hate pylint

Engineers love pylint because it catches real bugs and enforces consistency. They sometimes hate it because the signal-to-noise ratio can be high unless you configure it to your project. The best practice is to start with sensible defaults, invest in a .pylintrc file, and add rules gradually.

Resources and further learning

Official pylint website: https://www.pylint.org/

If you want structured Python training that covers code quality and tooling, check this course: Python Training — Essentials to Start.

Final tips — keep linting inspiring, not punitive

Linting should empower developers, not annoy them. Use pylint as a tool to improve developer experience and code clarity. Start small, measure improvements via pylint scores, and gradually tighten rules. Combine the speed of tools like flake8 or ruff with pylint’s depth for a pragmatic, high-quality workflow.

Alexandre Blanchet