Introduction

You can disable a Pylint warning at several scopes: one line, a block, a whole file, or the project configuration. The best choice depends on whether the warning is a one-off false positive or a rule your project intentionally does not want to enforce.

Disable a Warning Inline

For a single line, add a pylint: disable= comment.

value = some_dynamic_lookup()  # pylint: disable=no-member

This is the narrowest possible suppression and is usually the safest because it documents the exception exactly where it occurs.

You can disable multiple warnings on the same line too:

result = call_legacy_api()  # pylint: disable=no-member, no-value-for-parameter

Disable and Re-Enable Around a Block

If a warning applies to a short region rather than one line, disable it before the block and re-enable it afterward.

1# pylint: disable=too-many-locals
2def legacy_report():
3    total = 0
4    count = 0
5    errors = []
6    warnings = []
7    messages = []
8    status = "pending"
9    # more local variables here
10    return total, count, errors, warnings, messages, status
11# pylint: enable=too-many-locals

This is more precise than disabling the rule for the entire file.

Disable a Warning for a Whole File

If a file intentionally violates a rule throughout, place the directive near the top.

1# pylint: disable=missing-module-docstring
2
3def helper():
4    return 42

File-level suppression should be used carefully. It is sometimes appropriate for generated code, compatibility shims, or legacy modules, but it is usually too broad for routine development.

Use Message Names or Numeric Codes

Pylint warnings can be referred to by symbolic name or numeric code. Symbolic names are usually easier to understand and maintain.

Examples:

• 'unused-argument'
• 'no-member'
• 'missing-function-docstring'

A symbolic disable comment is easier to review than a numeric code that readers have to look up later.

Disable Rules in Configuration

If the whole project wants to relax a rule, put that decision in configuration rather than scattering disable comments everywhere.

In .pylintrc or pyproject.toml, depending on your setup, you can configure disabled messages globally.

Example .pylintrc style:

1[MESSAGES CONTROL]
2disable=
3    missing-module-docstring,
4    missing-function-docstring

This is appropriate when the team has intentionally decided not to enforce a rule project-wide.

Prefer Narrow Scope Over Broad Scope

A good rule of thumb is:

• one line if the issue is local
• block if a small section genuinely needs it
• file only when the whole file is special
• project config only when the team agrees the rule is not useful globally

This keeps suppressions honest and prevents a temporary exception from quietly turning into a permanent blind spot.

Suppression Should Be Explained When Non-Obvious

If the reason for disabling is not immediately clear, add a short explanation nearby.

config = plugin_registry.get(name)  # pylint: disable=no-member
# dynamic plugin objects are attached at runtime

That makes the suppression easier to review later and less likely to be mistaken for careless lint avoidance.

Common Pitfalls

The most common mistake is disabling warnings too broadly, especially at file or project scope, when a single-line suppression would have been enough. Another is using disable comments without understanding what the warning was trying to say in the first place. Developers also forget to remove old suppressions after refactoring, so the codebase accumulates stale exceptions that no longer serve a purpose.

Summary

• Use # pylint: disable=warning-name for narrow suppressions.
• Prefer symbolic warning names over numeric codes.
• Re-enable warnings after a block when the exception is temporary and local.
• Put project-wide rule decisions in config instead of repeated inline comments.
• Treat suppression as an exception that should stay as small and as well-explained as possible.