You might assume that a compiler or interpreter finds all the glitches and problems in a language's source code, but you would be wrong. While modern compilers and interpreters often perform some of these functions, a dedicated tool such as a lint is specifically designed to find potential problems in source code.

Stephen C. Johnson [1], a computer scientist at Bell Labs, coined the term "lint" in 1978. A lint is "a static code analysis tool used to flag programming errors, bugs, stylistic errors, and suspicious constructs" [2]. While a lint's warnings and errors are more recommendations than actual bugs, they help identify things that can lead to code bloat and security issues.

Using a linting tool can make your code more efficient, teach you to identify common problems in future code, and simplify your code review process. However, running a lint tool can be time-consuming, and it doesn't actually fix the code. It may flag issues that aren't really a problem in your source code (false positives), and it can lead to a false sense of security, because it can miss problems. Despite these drawbacks, a lint tool can help you optimize and improve your source code.

A Python Linter

For dynamically typed languages such as Python that do not typically enforce strict rules, lint tools can serve as a debugger. I wrote an open source Python linting tool, Py7 [3], while working on a large Python-based software project in order to familiarize team members with lint tools and help them anticipate, detect, and resolve many potential problems, resulting in better Python source code.

Py7 consists of seven separate Python lint tools (hence the name) rather than relying on a single lint tool. The idea is that seven independent tools are more likely to find a potential problem. When choosing the seven tools to incorporate into Py7, I took several design criteria into consideration:

• I wanted tools that addressed the function, operation, analysis, and security of Python source code instead of focusing on style or formatting.
• The tools couldn't explicitly require configuration files; any required defaults must be defined within Py7's Python source code.
• I wanted the checked Python source code to be immutable, so the tools couldn't alter code automatically.
• The tools had to be open source and available via pip, because Py7 needed the ability to automatically install a lint tool if it was not already installed in the Python environment.

Based on this criteria, I selected the following seven Python lint tools (listed in alphabetic order):

• Bandit [4]: Finds common security issues
• McCabe [5]: Checks the McCabe complexity
• Mypy [6]: Works as static type checker
• Pyflakes [7]: Checks source files for errors
• Pylint [8]: Analyzes and checks for errors
• Ruff [9]: Provides a fast Python code formatter and lint tool written in Rust
• Vulture [10]: Finds dead (unused) code

Three of the tools (Pyflakes, Pylint, and Ruff) all check the Python source code, providing an overlap, while the other four tools (Bandit, McCabe, Mypy, and Vulture) all have a specific linting focus.

The seven tools use different permissive open source code licenses (Apache 2.0, GPLv2, MIT License) that are available via GitHub.

Getting Started with Py7

Running Py7 is simple. For example, at the command line, enter the tool followed by the Python files you want to run Py7 on:

~>py7.py simple_proc.py pyke.py meminfo.py none.py

Except for the Python source code files, the only other command-line argument for Py7 is -h or --help, which provides information on how to use Py7. If the -h or --help argument is used, no linting checks are run. Instead, Py7 tells you how to use the tool and then exits.

When you use Py7 on your system for the first time, the tool checks to see if each of the seven tools are present in the Python environment. If Py7 detects that a tool is missing, it automatically installs that tool. If a tool is unable to be installed, Py7 will exit with an error message.

After Py7 checks for the tools, the script waits for the user to press a key, and then it runs all seven linting tools on all the Python source files specified. If a Python source file is not found, the Py7 tool continues to the next file. After completing all the tests, the Py7 tool waits for the user to acknowledge completing all the lint checks on all the Python source files.

The Py7 Script

The Py7 tool uses an "all-in-one" Python script (running on Python v3.13.2) that invokes the seven separate linting tools that perform the linting check of a Python source file. The first eight attributes in Listing 1 provide information about the Py7 script and are not used by the Py7 lint tool. Py7 uses the final two attributes, MACCABE_MIN and PY_MOD_LIST, for specific functions, which I will cover later.

__author__ = "William F. Gilreath"
__copyright__ = "Copyright 2025"
__credits__ = ["William F. Gilreath"]
__license__ = "GPL"
__version__ = "v3.0"
__maintainer__ = "William F. Gilreath"
__email__ = "william.f.gilreath@gmail.com"
__release__ = "v 1.3.2"
MCCABE_MIN = '3'
PY_MOD_LIST = ['bandit','mccabe','mypy','pyflakes','pylint','ruff','vulture',]

The structure of the Py7 tool Python script is organized into five functions: main(), check_modules(), run_lint_tests(), usage(), and version().

Py7's core functionality is in the main(), check_modules(), and run_lint_tests(), which do the lint check of the Python source file. The usage() and version() functions provide information about the Py7 tool, and thus do not affect the linting process.