Home » Python » How do I disable a Pylint warning?

How do I disable a Pylint warning?

Posted by: admin November 1, 2017 Leave a comment


I’m trying to disable warning C0321 (“more than one statement on a single line” — I often put if statements with short single-line results on the same line), in Pylint 0.21.1 (if it matters: astng 0.20.1, common 0.50.3, Python 2.6.6 (r266:84292, Sep 15 2010, 16:22:56)).

I’ve tried adding disable=C0321 in the Pylint configuration file, but Pylint insists on reporting it anyway. Variations on that line (like disable=0321 or disable=C321) are flagged as errors, so Pylint does recognize the option properly, it’s just ignoring it.

Is this a Pylint bug, or am I doing something wrong? Is there any way around this? I’d really like to get rid of some of this noise.


pylint --generate-rcfile shows it like this:


# Enable the message, report, category or checker with the given id(s). You can
# either give multiple identifier separated by comma (,) or put this option
# multiple time.

# Disable the message, report, category or checker with the given id(s). You
# can either give multiple identifier separated by comma (,) or put this option
# multiple time (only on the command line, not in the configuration file where
# it should appear only once).

So it looks like your ~/.pylintrc should have the disable= line/s in it inside a section [MESSAGES CONTROL].


I had this problem using Eclipse and solved it as follows:

in the pylint folder (e.g. C:\Python26\Lib\site-packages\pylint), hold shift, right-click and choose to open the windows command in that folder. Type:

lint.py --generate-rcfile > standard.rc

This creates the ‘standard.rc’ configuration file. Open it in notepad and under ‘[MESSAGES CONTROL]’, uncomment
‘disable=’ and add the message ID’s you want to disable, e.g.:

disable=W0511, C0321

Save the file, and in Eclipse->window->preferences->PyDev->pylint, in the arguments box, type:


Now it should work …

You can also add a comment at the top of your code that will be interpreted by pylint:

# pylint: disable=C0321

link to all pylint message codes

Adding e.g. --disable-ids=C0321 in the arguments box does not work.
All available pylint messages are stored in the dictionary ‘_messages’, an attribute of an instance of the pylint.utils.MessagesHandlerMixIn class. When running pylint with the argument --disable-ids=... (at least without a config file), this dictionary is initially empty, raising a KeyError exception within pylint (pylint.utils.MessagesHandlerMixIn.check_message_id().
In Eclipse, you can see this error-message in the Pylint Console (windows – show view – Console, select Pylint console from the console options besides the console icon.)


Starting from Pylint v. 0.25.3, you can use the symbolic names for messages instead of remembering all those code numbers. E.g.:

# pylint: disable=locally-disabled, multiple-statements, fixme, line-too-long

The above comment can be inserted at the end of the line for which it is meant to apply. In this case, include locally-disabled first as is above, failing which a “Locally disabling” message may be included by pylint. If however you then receive a useless-suppression message, remove locally-disabled.

This style is IMHO more practical than disabling the error code, especially since newer versions of Pylint only output the symbolic name, not the error code.


To disable a warning locally in a block, add

# pylint: disable=C0321

to that block.


There are several ways to disable warnings & errors from Pylint. Which one to use has to do with how globally or locally you want to apply the disablement — an important design decision.

Multiple Approaches

  1. In one or more pylintrc files.

This involves more than the ~/.pylintrc file (in your $HOME directory) as described by Chris Morgan. Pylint will search for rc files, with a precedence that values “closer” files more highly:

  • A pylintrc file in the current working directory; or

  • If the current working directory is in a Python module (i.e. it contains an __init__.py file), searching up the hierarchy of Python modules until a pylintrc file is found; or

  • The file named by the environment variable PYLINTRC; or

  • If you have a home directory that isn’t /root:

    • ~/.pylintrc; or

    • ~/.config/pylintrc; or

    • /etc/pylintrc

Note that most of these files are named pylintrc — only the file in ~ has a leading dot.

To your pylintrc file, add lines to disable specific pylint messages. For example:

  1. Further disables from the pylint command line, as described by Aboo and Cairnarvon. This looks like pylint --disable=bad-builtin. Repeat --disable to suppress additional items.

  2. Further disables from individual Python code lines, as described by Imolit. These look like some statement # pylint: disable=broad-except (extra comment on the end of the original source line) and apply only to the current line. My approach is to always put these on the end of other lines of code so they won’t be confused with the block style, see below.

  3. Further disables defined for larger blocks of Python code, up to complete source files.

    • These look like # pragma pylint: disable=bad-whitespace (note the pragma key word).

    • These apply to every line after the pragma. Putting a block of these at the top of a file makes the suppressions apply to the whole file. Putting the same block lower in the file makes them apply only to lines following the block. My approach is to always put these on a line of their own so they won’t be confused with the single-line style, see above.

    • When a suppression should only apply within a span of code, use # pragma pylint: enable=bad-whitespace (now using enable not disable) to stop suppressing.

Note that disabling for a single line uses the # pylint syntax while disabling for this line onward uses the # pragma pylint syntax. These are easy to confuse especially when copying & pasting.

Putting It All Together

I usually use a mix of these approaches.

  • I use ~/.pylintrc for absolutely global standards — very few of these.

  • I use project-level pylintrc at different levels within Python modules when there are project-specific standards. Especially when you’re taking in code from another person or team, you may find they use conventions that you don’t prefer, but you don’t want to rework the code. Keeping the settings at this level helps not spread those practices to other projects.

  • I use the block style pragmas at the top of single source files. I like to turn the pragmas off (stop suppressing messages) in the heat of development even for Pylint standards I don’t agree with (like “too few public methods” — I always get that warning on custom Exception classes) — but it’s helpful to see more / maybe all Pylint messages while you’re developing. That way you can find the cases you want to address with single-line pragmas (see below), or just add comments for the next developer to explain why that warning is OK in this case.

  • I leave some of the block-style pragmas enabled even when the code is ready to check in. I try to use few of those, but when it makes sense for the module, it’s OK to do as documentation. However I try to leave as few on as possible, preferably none.

  • I use the single-line-comment style to address especially potent errors. For example, if there’s a place where it actually makes sense to do except Exception as exc, I put the # pylint: disable=broad-except on that line instead of a more global approach because this is a strange exception and needs to be called out, basically as a form of documentation.

Like everything else in Python, you can act at different levels of indirection. My advice is to think about what belongs at what level so you don’t end up with a too-lenient approach to Pylint.


You can also use the following command:

pylint --disable=C0321  test.py

My pylint version is 0.25.1.


This is a FAQ:

4.1 Is it possible to locally disable a particular message?

Yes, this feature has been added in Pylint 0.11. This may be done by
“#pylint: disable=some-message,another-one” at the desired
block level or at the end of the desired line of code.

You can disable messages either by code or by symbolic name. See the docs (or run pylint --list-msgs in the terminal) for the full list of pylint’s messages.
The docs also provide a nice example of how to use this feature.


In case this helps someone, if you’re using Visual Studio Code, it expects the file to be in UTF8 encoding. To generate the file, I ran pylint --generate-rcfile | out-file -encoding utf8 .pylintrc in PowerShell.