Find what settings influence a given Pylint message

Question

When Pylint warns me about something, how can I know what settings it's applying? And what section of .pylintrc this setting goes in?

For example:

• Used builtin function 'map'. Using a list comprehension can be clearer. (bad-builtin) is because bad-functions in [BASIC] contains map.
• Missing function docstring (missing-docstring) is conditional on docstring-min-length in [BASIC].
• invalid-name obeys several [BASIC] settings: variable-rgx, method-rgx, module-rgx, etc.

I expected to find this information in the Pylint documentation but it generally doesn't provide this information. For example, there's no link from the documentation of missing-docstring or invalid-names to the applicable options. With bad-builtin, the information is easy to find, but only because it's from a specific extension. The Pylint message wiki has explanations about what the message means, but not what brought it up. The comments in pylint --generate-rcfile don't relate the settings to warning codenames either (nothing there explains that e.g. bad-functions influences the bad-builtin message).

The reason I'm asking this is that in many cases, Pylint's conventions don't match my project's needs and conventions, and I want to tune it rather than ignore specific instances or ignore messages wholesale (so I'm not looking for disable=!). So how do I find what to tune?

Answer 1

How do I find what to tune?

So it seems like you're asking about how you can determine the combination of factors that lead to a pylint message being raised. Using the bad-builtin example, a warning message that is not listed at all in the .pylintrc, a helpful verbose message would be:

bad-builtin: Used builtin function 'map'. Using a list comprehension can be clearer.

---> (Hypothetical) VERBOSE OUTPUT:

bad-builtin was raised because the bad-functions setting in your .pylintrc under the [BASIC] section contains the function map. If you want to "tune" this behavior look here.

Short answer: I am not sure this exists.

When you run pylint my_file.py the first thing it should tell you is the configuration file it is using. From there, you want to find the .pylintrc in use or else you want to create it. Otherwise it will be using the default configuration. If pylint does not tell you what config you are using you can figure out your current pylintrc configuration by running something like:

pylint --generate-rcfile &> output.txt

When you inspect output.txt it should look like this example pylintrc. It is organized into different categories. You can get more info on this without generating an rcfile by running pylint --long-help. The sections include:

[MASTER]
[MESSAGES CONTROL]
[REPORTS]
[BASIC]
[ELIF]
[TYPECHECK]
[FORMAT]
[MISCELLANEOUS]
[VARIABLES]
[LOGGING]
[SIMILARITIES]
[SPELLING]
[IMPORTS]
[DESIGN]
[CLASSES]
[EXCEPTIONS]

I am not sure what you mean by, "The Pylint message wiki has explanations about what the message means, but not what brought it up." When I run pylint on a file or in a code base it tells me exactly where the offending line is.

Then I usually either:

• Fix the warning
• Disable the warning
• Modify the .pylintrc to meet my needs

If you want to tune a specific message type but you are not sure how to do so, then I think you are right that is something that could be better documented. The question: Is XYZ warning message 'tunable'? Or is the only option to fix OR disable? This page lists the pylint features but I do not see anything about bad built-in, for example, let alone the options that are available to apply to a message type.

UPDATE: I am not sure what version of pylint you are on, but it looks like the bad-builtin was specifically addressed in pylint version 1.6. I was going to say we should look at what is going on in the actual source code to generate this message, but I think that requires figuring out what version of pylint you are on first, then digging into the code, then figuring out how to tune it? I agree that the docs can be more clear on how to tune specific warnings:

The bad-builtin check was moved into an extension.

The check was complaining about used builtin functions which were supposed to not be used. For instance, map and filter were falling into this category, since better alternatives can be used, such as list comprehensions. But the check was annoying, since using map or filter can have its use cases and as such, we decided to move it to an extension check instead. It can now be enabled through --load-plugins=pylint.extensions.bad_builtin.