Bug reports, feedback

You think you have found a bug in Pylint? Well, this may be the case since Pylint is under development.

Please take the time to check if it is already in the issue tracker at

If you can not find it in the tracker, create a new issue there or discuss your problem on the mailing list.

The code-quality mailing list is also a nice place to provide feedback about Pylint, since it is shared with other tools that aim at improving the quality of python code.

Note that if you don’t find something you have expected in Pylint’s issue tracker, it may be because it is an issue with one of its dependencies, namely astroid.

Mailing lists

Use the mailing list for anything related to Pylint. This is in most cases better than sending an email directly to the author, since others will benefit from the exchange, and you’ll be more likely answered by someone subscribed to the list.

You can subscribe to this mailing list at

Archives are available at

Archives before April 2013 are available at


Pylint is developed using the mercurial distributed version control system.

You can clone Pylint and its dependencies from

hg clone
hg clone
hg clone

Got a change for Pylint? Below are a few steps you should take to make sure your patch gets accepted.

  • Test your code

    • Pylint keeps a set of unit tests in the /test directory. The module uses external files to have some kind of easy functional testing. To get your patch accepted you must write (or change) a test input file in the test/input directory and message file in the test/messages directory. Then run python to ensure that your test is green.
    • You should also run all the tests to ensure that your change isn’t breaking one.
  • Add a short entry to the ChangeLog describing the change, except for internal implementation only changes

  • Write a comprehensive commit message

  • Relate your change to an issue in the tracker if such an issue exists (see this page of Bitbucket documentation for more information on this)

  • Send a pull request from Bitbucket (more on this here)

Unit test setup

If you have tox installed, running tox command should be enough to get you started. Otherwise, you can follow this recipe for running the tests for pylint:

python develop # or ``pip install -e .``
cd pylint/test
python -m unittest discover -p "*test*"

Adding new functional tests

Pylint comes with an easy way to write functional tests for new checks:

  • put a Python file in the test/input directory, whose name starts with func_ and should also contains the symbolic name of the tested check
  • add the expected message file in the test/messages directory, using the same name but a .txt extension instead of .py

The message file should use the default text output format (without reports) and lines should be sorted. E.g on Unix system, you may generate it using:

pylint -rn input/ | sort > pylint messages/func_mycheck.txt

Also, here are a few naming convention which are used:

  • Python files starting with ‘func_noerror’ don’t have any message file associated as they are expected to provide no output at all
  • You may provide different input files (and associated output) depending on the Python interpreter version:
    • tests whose name ends with _py<xy>.py are used for Python >= x.y
    • tests whose name ends with _py<_xy>.py are used for Python < x.y
  • Similarly you may provide different message files for a single input, message file whose name ends with ‘_py<xy>.txt’ will be used for Python >= x.y, using the nearest version possible

Table Of Contents

Previous topic


Next topic

A Beginner’s Guide to Code Standards in Python - Pylint Tutorial

This Page