Pylint Reporters

Purpose of Reporters in Pylint

Reporters display messages when they are available. Each of the messages focuses on a particular aspect of the project, such as number of messages by categories. Right after, a global evaluation of the code is evaluated.

Taken from pylint.readthedocs.io

For instance, the metrics report displays summaries gathered from the current run.

• the number of processed modules
• for each module, the percentage of errors and warnings
• the total number of errors and warnings
• percentage of classes, functions and modules with docstrings, and a comparison from the previous run
• percentage of classes, functions and modules with correct name (according to the coding standard), and a comparison from the previous run
• a list of external dependencies found in the code, and where they appear

More information about Pylint and reporters in Pylint:

• Pylint doc
  https://pylint.readthedocs.io/en/latest/
• Pylint reporters files
  https://github.com/PyCQA/pylint/tree/master/pylint/reporters

Usage of Reporters in PyTA

When a user calls python_ta.check_all() to check a piece of code, ColorReporter and PlainReporter are also called and they:

• 1. Piggyback on methods in Pylinter class https://github.com/PyCQA/pylint/blob/master/pylint/lint.py
• 2. Overwrite the way PyLint reports errors to messages that are easier to read (Print statement)

More information about python_ta.check_all() and PyTA's custom reporters:

• python_ta
  https://github.com/pyta-uoft/pyta/blob/master/python_ta/__init__.py
• PyTA's custom reporters https://github.com/pyta-uoft/pyta/tree/master/python_ta/reporters

Methods that should be implemented for every reporter

If your reporters are subclasses of BaseReporter, there are two main methods you should consider in addition to the instance method.

• instance(self) You should initialize an empty list here to store the messages for later use.

• handle_message(self, msg) This method lets you handle the given msg obg. handle_message must be overwritten from Pylint's default handle_message in your own reporter should you choose to use MessagesHandlerMixIn's very useful method add_message. This is because at the very end, the following lines are executed:

  self.reporter.handle_message(Message(msgid, symbol, (abspath, path, module, obj, line or 1, col_offset or 0), msg, confidence))

BaseReporter expects that its subclasses will each have its own handle_message function.

• _display(self, layout) Essentially, what do you want to do with all the data? This should be implemented if you plan on using BaseReporter's display_reports method, which is useful for if you have a Tree. How do you want to display what you have collected? However, if you choose not to continue with BaseChecker's Tree, you could rewrite this into a "print_messages" method.

  def display_reports(self, layout): """display results encapsulated in the layout tree""" self.section = 0 if hasattr(layout, 'report_id'): layout.children[0].children[0].data += ' (%s)' % layout.report_id self._display(layout)

Methods that can be implemented for every reporter

In addition to what are already shown in BaseReporter and JsonReporter, you could have methods to

• reset the reporter
• print messages (as an alternative/addition to _display)
• sort messages
• handle coding errors only
• handle style errors only

Examples implemented can be found here.

How is a reporter notified of an error?

As previously mentioned, when a user calls python_ta.check_all() to check a piece of code, ColorReporter and PlainReporter are also called, which means BaseReporter is called eventually.

These are the steps from collecting errors to eventually displaying them in PyTA.

• Under _check, current_reporter initializes ColorReporter
• ColorReporter is set to PyLinter's reporter param
• The checkers get to work. Please refer to Checkers for more information