Pylint is a static code checker, meaning it can analyse your code without actually running it. Pylint checks for errors, tries to enforce a coding standard, and tries to enforce a coding style.
A major difference between Pylint and Pychecker is that Pylint checks for style issues, while Pychecker explicitly does not. There are a few other differences, such as the fact that Pylint does not import live modules while Pychecker does (see 6.2 Why does Pychecker catch problems with imports that Pylint doesn’t?).
Pylint’s main author and maintainer for the first ten years of its life has been Sylvain Thénault, while he worked at Logilab where the project was born. For a full list of contributors, see the “Contributors” section of Pylint’s README file.
Everybody knows someone who uses Pylint.
Pylint uses the Mercurial distributed version control system. The URL of the repository is: https://bitbucket.org/logilab/pylint. To get the latest version of Pylint from the repository, simply invoke
hg clone https://bitbucket.org/logilab/pylint
Since Pylint 1.4, we support only Python 2.7+ and Python 3.3+. Using this strategy really helps in maintaining a code base compatible with both versions and from this benefits not only the maintainers, but the end users as well, because it’s easier to add and test new features. If support for Python 2.6 is absolutely required, then the version from pylint-1.3 branch can be used. It will receive backports of bug fixes for a while.
Pylint expects the name of a package or module as its argument. As a convenience, you can give it a file name if it’s possible to guess a module name from the file’s path using the python path. Some examples :
“pylint mymodule.py” should always work since the current working directory is automatically added on top of the python path
“pylint directory/mymodule.py” will work if “directory” is a python package (i.e. has an __init__.py file) or if “directory” is in the python path.
“pylint /whatever/directory/mymodule.py” will work if either:
- “/whatever/directory” is in the python path
- your cwd is “/whatever/directory”
- “directory” is a python package and “/whatever” is in the python path
- “directory” is a python package and your cwd is “/whatever” and so on...
Analysis data are stored as a pickle file in a directory which is localized using the following rules:
value of the PYLINTHOME environment variable if set
(not always findable on Windows platforms)
”.pylint.d” directory in the current directory
You can always generate a sample pylintrc file with –generate-rcfile Every option present on the command line before this will be included in the rc file
pylint --disable=bare-except,invalid-name --class-rgx='[A-Z][a-z]+' --generate-rcfile
Yes, this feature has been added in Pylint 0.11. This may be done by adding “#pylint: disable=some-message,another-one” at the desired block level or at the end of the desired line of code
Yes, you can disable or enable (globally disabled) messages at the module level by adding the corresponding option in a comment at the top of the file:
# pylint: disable=wildcard-import, method-hidden # pylint: enable=too-many-lines
With Pylint < 0.25, add “#pylint: disable-all” at the beginning of the module. Pylint 0.26.1 and up have renamed that directive to “#pylint: skip-file” (but the first version will be kept for backward compatibility).
In order to ease finding which modules are ignored a Information-level message file-ignored is emited. With recent versions of Pylint, if you use the old syntax, an additional deprecated-disable-all message is emited.
No, starting from 0.25.3, you can use symbolic names for messages:
# pylint: disable=fixme, line-too-long
Prefix (ui) the callback’s name by cb_, as in cb_onclick(...). By doing so arguments usage won’t be checked. Another solution is to use one of the names defined in the “dummy-variables” configuration variable for unused argument (“_” and “dummy” by default).
Pylint uses ConfigParser from the standard library to parse the configuration file. It means that if you need to disable a lot of messages, you can use tricks like:
# disable wildcard-import, method-hidden and too-many-lines because I do # not want it disable= wildcard-import, method-hidden, too-many-lines
A class is considered as an interface if there is a class named “Interface” somewhere in its inheritance tree.
Pylint is using the Zope 2 interfaces conventions, and so is considering that a class is implementing interfaces listed in its __implements__ attribute.
A class is considered as an abstract class if at least one of its methods is doing nothing but raising NotImplementedError.
To do so you have to set the ignore-mixin-members option to “yes” (this is the default value) and to name your mixin class with a name which ends with “mixin” (whatever case).
Even though the final rating Pylint renders is nominally out of ten, there’s no lower bound on it. By default, the formula to calculate score is
10.0 - ((float(5 * error + warning + refactor + convention) / statement) * 10)
However, this option can be changed in the Pylint rc file. If having negative values really bugs you, you can set the formula to be the maximum of 0 and the above expression.
Pychecker and Pylint use different approaches. pychecker imports the modules and rummages around in the result, hence it sees my mangled sys.path. Pylint doesn’t import any of the candidate modules and thus doesn’t include any of import’s side effects (good and bad). It traverses an AST representation of the code.