Introduction

If you want to suppress missing-docstring warnings for one Python file, the usual solution is a file-level Pylint directive near the top of that file. The important detail is that newer Pylint versions split missing-docstring checks into separate message names for modules, classes, and functions, so it is often better to disable the exact warnings you mean.

Use a File-Level Pylint Comment

Place a directive near the top of the file, usually right after the shebang or encoding comment if those exist.

1# pylint: disable=missing-module-docstring,missing-class-docstring,missing-function-docstring
2
3class Demo:
4    def run(self):
5        return "ok"

That disables the three missing-docstring warnings for that file only.

In some older Pylint versions or codebases, you may also see the legacy symbolic form:

# pylint: disable=missing-docstring

The more specific names are usually clearer because they show exactly what is being suppressed.

Use Numeric Codes if Needed

Pylint also supports numeric message IDs. For missing docstrings, the common ones are:

• 'C0114 for missing module docstring,'
• 'C0115 for missing class docstring,'
• 'C0116 for missing function or method docstring.'

That means this works too:

# pylint: disable=C0114,C0115,C0116

Symbolic names are often easier to read later, but numeric codes are useful if your team already works with message IDs.

Why File-Level Disables Are Useful

A file-level disable can make sense for:

• generated code,
• migration files,
• test fixtures,
• experimental scripts,
• intentionally tiny modules where full docstrings add little value.

This is usually better than disabling the warning globally for the whole project when only one or two files are the exception.

Prefer Narrow Suppression Over Global Suppression

If you disable missing-docstring warnings globally in .pylintrc or pyproject.toml, you remove the check everywhere. A file-level directive keeps the exception local.

That makes review easier because future readers can see that the suppression was intentional and limited in scope.

It also gives you a cleaner migration path. A team can later remove the file-level directive from one module at a time instead of undoing a broad global disable across the whole repository.

Keep the Directive Near the Top

Pylint reads these directives from comments in the file, so placement matters. Put the disable comment early enough that it applies to the whole module.

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

If you put the comment too late, earlier definitions may still trigger warnings.

If your project uses pyproject.toml or a shared Pylint config, keep the local disable focused on the exceptional file and leave the broader policy in the central configuration.

That balance keeps local intent visible while preserving a consistent project-wide lint standard.

Common Pitfalls

• Using the old missing-docstring name in a codebase where the newer granular names are clearer.
• Disabling docstring warnings globally when only one file needs an exception.
• Putting the directive too low in the file.
• Suppressing the warning without documenting why the file is an exception.
• Forgetting that module, class, and function docstrings are separate checks in newer Pylint versions.

Summary

• Use a file-level # pylint: disable=... comment near the top of the file.
• Prefer missing-module-docstring, missing-class-docstring, and missing-function-docstring for clarity.
• Numeric IDs such as C0114, C0115, and C0116 also work.
• File-level suppression is better than global suppression when only one file is special.
• Keep the directive early and as narrow as possible.