DEV Community

Adam Parkin
Adam Parkin

Posted on • Originally published at codependentcodr.com on

Disabling Pylint Messages

This post was originally posted on Aug 12, 2018 to https://www.codependentcodr.com/disabling-pylint-messages.html#disabling-pylint-messages

Small tip of the day since I keep having to look this up. If you use
Pylint for static analysis of your code, you might find that you'll want to disable a particular rule for a particular line or file. That is, you don't want to permanently disable this rule, but just for this one special spot where the rule doesn't make sense.

I find this particularly common in unit test code as my test method names tend to be long, violating rule C0103 "Name doesn't conform to naming rules". For example, a test name might look like:

def test_message_builder_generates_correct_bytestring_when_no_argument_supplied():
Enter fullscreen mode Exit fullscreen mode

Which is very self-descriptive, and when that test fails, it makes it much
easier to figure out what might've gone wrong. The problem is that Pylint will flag that line since it's greater than 30 characters long, violating the style
guidelines. We could disable this rule across the entire codebase, but outside
of tests, the rule makes sense.

This is where local disables come in, which take the form of comments:

# pylint disable=C0103
def test_message_builder_generates_correct_bytestring_when_no_argument_supplied():
Enter fullscreen mode Exit fullscreen mode

This will suppress code C0103 for the remainder of the scope (module or block), or until it's re-enabled:

# pylint disable=C0103
def test_message_builder_generates_correct_bytestring_when_no_argument_supplied():


# still disabled here...

# pylint enable=C0103
def but_not_disabled_here_so_this_name_will_get_flagged_by_pylint():
Enter fullscreen mode Exit fullscreen mode

You can also (and it's generally better practice) use the "verbose name" for a
particular code rather than the shorthand code. For example, this is
equivalent:

# pylint disable=invalid-name
def test_message_builder_generates_correct_bytestring_when_no_argument_supplied():
Enter fullscreen mode Exit fullscreen mode

A question then becomes "how do I know what the verbose name for a code is?" And the answer is to use the --list-msgs argument to Pylint on the command line, and it'll spit them all out:

$ pylint --list-msgs
:blacklisted-name (C0102): *Black listed name "%s"*
  Used when the name is listed in the black list (unauthorized names).
:invalid-name (C0103): *%s name "%s" doesn't conform to %s*
  Used when the name doesn't conform to naming rules associated to its type
  (constant, variable, class...).
:missing-docstring (C0111): *Missing %s docstring*
  Used when a module, function, class or method has no docstring.Some special
  methods like __init__ doesn't necessary require a docstring.
:empty-docstring (C0112): *Empty %s docstring*
  Used when a module, function, class or method has an empty docstring (it would
  be too easy ;).

... more lines ...
Enter fullscreen mode Exit fullscreen mode

One extra tip about Pylint: if you use Visual Studio Code you can turn on Pylint as your linter, and warnings will get put into the problems view. To turn it on set the following in your VS Code settings (assuming you've installed the Python extension from Microsoft):

"python.linting.enabled": true,
"python.linting.pylintEnabled": true,
Enter fullscreen mode Exit fullscreen mode

Note that these are both on by default (at least in the current version). Once you save a Python file, Pylint warnings will show up in the problems view:

Pylint Warnings in VS Code Problems View

Note that that screenshot also illustrates how you can filter the problems view down to show just Pylint warnings by entering "pylint" into the search box. Also note that clicking any of those will open up that file in VS Code and navigate to the line in question. Really handy.

Top comments (0)