Explain Codes LogoExplain Codes Logo

Is it possible to ignore one single specific line with Pylint?

python
linting
pylint
code-quality
Anton ShumikhinbyAnton Shumikhin·Sep 19, 2024
TLDR

Yes, add the comment # pylint: disable=warning-name to the end of the line you want Pylint to ignore. Replace warning-name with the Pylint warning ID that you want ignored. Example:

variable = "value" # pylint: disable=unused-variable

Guide to Pylint messages

Knowing your warning name or code can help you. It comes in two handy formats:

  • Symbolic names like unused-variable
  • Message codes like W0612

For instance, disabling an unused import could look like this:

import os # pylint: disable=unused-import # 'os' has feelings too, but sometimes you just aren't needed.

Or using the message code:

import os # pylint: disable=W0611 # 'os' is upset! It's getting the W0611 treatment now!

To find the right message name or code, you can check the Pylint's GitHub page or the extensive Pylint wiki.

Taking control of the scope of warning suppression

Using inline exemption offers the ability to control at a granular level. Yet, sometimes you want to re-enable a warning:

# pylint: disable=too-many-arguments def function_with_many_args(): ... # pylint: enable=too-many-arguments # Welcome back, arguments! We missed you.

From Pylint 2.10, the disable-next was introduced to ignore the next line only:

# pylint: disable-next=invalid-name WeirdName = 42 # Because sometimes, we love the weird ones.

Want more control? Visit the Pylint message control documentation for more insights.

IDEs and the art of effortless suppression

Modern integrated development environments (IDEs) like Eclipse or PyCharm have inbuilt linting tools that automatically provide solutions for Pylint errors. Some even add the necessary comment with a click or shortcut. Make sure to check the PEP 8 guidelines on safer code with proper spacing for comments to avoid additional formatting warnings.

When suppression needs a different approach

While inline exemptions can be handy, a larger scope may be needed for project-wide false positives. Alter your .pylintrc configuration file to manage globally disabled warnings globally, keeping your code free from constant Pylint directives. A wider approach helps to maintain code readability.

Remember, refactoring your code based on Pylint's suggestions helps promote healthier, more maintainable code.