Python Debugger Showdown

318 VIEWS

Debuggers.  Maybe you don’t always need them, but when you do, you need one that can give you comprehensive insight into your code, and make it easy to quickly track down problems.

In this post, we’ll take a look at some of the most popular Python debuggers to see how they measure up against each other, and to give you a chance to decide which debugger is right for your Python projects.

Let’s start with the basics: Python’s built-in pdb.

 

Pdb: The Native Python Debugger

Python’s default debugger, pdb, is a no-frills module with a strictly command-line interface.  You can use it to perform basic debugging tasks such as stepping through code, post-mortem debugging, displaying the values of specified code elements, and stack frame inspection.  You can set hard breakpoints using the in-line command import pdb; pdb.set_trace() (which starts the debugger at the location where it’s placed), or use the break or tbreak commands to set persistent or temporary breakpoints from the debugger prompt.

pdb can also be set to skip specified code elements, to execute statements, and to evaluate specified functions.  You can move through the stack trace, manage breakpoints, jump to arbitrary locations in the code, and combine commands into aliases.  Commands (including aliases) can be placed in a file named .pdbrc, which will be loaded automatically if it is present when you run pdb, providing a considerable degree of scriptability.

pdb is certainly a step above no-debugger debugging, but it is definitely a classic example of the bare-bones, CLI-only school of debuggers.

Pros:

  • Convenient for smaller projects with relatively simple debugging requirements since it has minimal overhead.

Cons:

  • For a project of any size or complexity, pdb’s CLI-only approach can prove frustrating.
  • Evaluates individual variables and expressions only when specifically commanded to do so (rather than providing a list of those that are currently in use), and it does not allow you to edit those values.

 

Visual/Graphic Debugger Comparison

CLI-only debuggers are largely a thing of the past. Modern debuggers are GUI-based, and typically either part of an Integrated Development Environment (IDE), or an editing system with IDE capabilities.  These include:

  • PyCharm, which is a Python-Specific IDE developed by JetBrains.
  • Visual Studio, which is developed by Microsoft and comes in two basic flavors:
    • Visual Studio 2019, a full-featured, multi-language IDE that runs on Windows and macOS, and
    • Visual Studio Code (vscode), a lightweight, multi-language IDE/editor that runs on Windows, macOS and Linux.
  • Komodo, which is a full-featured, multi-language IDE developed by ActiveState. It runs on Windows, macOS, and Linux, and is designed for mixed-language environments.

Before we look at the differences between these debugging environments, here’s a quick rundown of the basic features that they have in common:

 

Debugger Commonalities: General Operation

  • They all work with a range of common Python interpreters.
  • They all include built-in code editors and an extensive set of tools for managing development projects.
  • While they are all designed to work with full development projects, they will run and debug individual code files not associated with a project.
  • They all support a variety of plug-ins and extensions for adding functionality, and customizing the user interface.
  • They all include professional and free community versions.

 

Debugger Commonalities: Debugging

  • They all feature debugging commands (including those found in pdb, or the equivalent) are available through the GUI.
  • They all display information about execution, output, and debugging in multiple windows, making it easier to find and identify specific types of debugger output.
  • They all provide debugger output at breakpoints that include an extensive list of variables with data types and values.
  • They all allow variable values to be manually set during pauses in execution/debugging.
  • They all allow individual variables to be added to a watch list, with watch output in a separate window.

 

Debugger Showdown

While PyCharm, Visual Studio, vscode and Komodo all share a number of features, they also have a number of key differences. Where do they shine, and where are they not so shiny?

 

Debugger Showdown: Basic Debugging

We’ll start with some basic ease-of-use issues.  Let’s say we just want to open a Python file and debug it.  First, how do we open the file?

Running on Windows, both Komodo and vscode use the standard Windows Open File interface.  PyCharm uses a nonstandard interface which, while it is hardly difficult to use, does take a bit of getting used to.  Visual Studio 2019, on the other hand, starts out with a repository/project/folder-oriented Getting Started screen. After you make a selection, however, it shifts to the standard Windows Open File interface.

After you select a file, each of the IDEs opens it in the editor window without any additional prompts.  What do you have to do to debug it?

All four IDEs have Debug menus with a reasonably good range of options (in PyCharm, the Debug menu is named “Run”).  After you select the Debug option (“Go/Continue” in Komodo), both versions of Visual Studio simply run the debugger, while Komodo and PyCharm prompt you with dialog boxes asking you to set debugging options.

if you select the defaults in Komodo, the debugger runs without any further prompts.  PyCharm, on the other hand, requires you to select an interpreter for the project (if one is not already set as part of the project environment) using the Edit menu’s Settings dialog box in a process that is far from intuitive. (See below for more on interpreter selection.)

 

Debugger Showdown: Setting a Breakpoint

Setting a breakpoint is simple in Komodo – you click on the line number (or just to the left of it), and the standard red breakpoint symbol appears.  You can manage the breakpoint and set options for it using the right-click context menu’s Debug submenu.

In PyCharm and both flavors of Visual Studio, the process is similar, but with some ease-of-use and functional differences.  For example, PyCharm and vscode are both rather picky about just where you should click (next to the line number, but not on it), and both flavors of Visual Studio have rather awkward interfaces (and somewhat limited options) for editing breakpoints.

 

Debugger Showdown: Language Detection and Interpreter Selection

You can’t debug even the simplest line of code unless you know what language it’s written in, and which interpreter or compiler it requires.  The IDE/debuggers that we’re looking at today represent very different approaches to the closely-related processes of language detection and interpreter selection.

With PyCharm, the problem of language selection is more or less trivial, since it’s a Python-only IDE.  As we indicated above, however, it does not automatically look for or accept a system default for the Python interpreter. Rather, you need to manually set the interpreter on a project-by-project basis.

Both versions of Visual Studio, on the other hand, follow the standard Microsoft practice of identifying file types (and in this case, their associated programming languages) by extension.  They accept default interpreters based on the system’s environment and path settings. You can change interpreters, but for both versions of Visual Studio the commands for doing this are not easy to find, and the process is somewhat less than self-explanatory.

Komodo takes a more sophisticated (and more flexible) approach to language detection.  It uses both extensions and analysis of file content to determine language, and is capable of detecting multiple languages in a single file.  In addition, you can manually assign a language to each file individually using a menu on the top bar of the editor window. For Python, there are separate options for Python 2 (“Python”) and Python 3 (“Python3”).

Like Visual Studio, Komodo assigns interpreters (separately for “Python” and “Python3”) based on the system’s environment settings. Unlike Visual Studio, however, manually assigning interpreters (under “Languages” in the Edit menu’s Preferences dialog box) turns out to be a simple and reasonably intuitive task.

 

Debugger Showdown: Mixed-Language Development

Many, if not most contemporary large software development projects are not single-language.  Unlike typical development projects of the past (including the DOS and Windows desktop eras), they are much less likely to be constrained by the need to fit within the scope of a single operating system or compiler.  The choice of language can depend on the task (database access, manipulating large text files, graphic display, etc.), the operating environment (i.e., a browser window, virtualized backend Linux, or a Windows desktop), compatibility with existing code, or a variety of other factors.

As stated previously, PyCharm isn’t designed to address multi-language issues. Visual Studio 2019 and vscode are equipped to handle multiple languages, but their relatively basic and inflexible methods of identifying languages reflect the built-in limitations of their desktop-era legacy.

Komodo, on the other hand, is designed specifically for today’s large, multi-language projects.  It is designed to handle projects that include frequent inline language changes within individual files, and that require distinctions between different versions of the same language.

 

Python Debugger: Which Is Best?

Komodo, both as an overall multi-language IDE as well as a Python development and debugging environment, is built on the belief that in a world where infrastructure itself is virtualized and can be tailored to the application’s requirements (rather than the other way around), you should not be constrained by the development environment.

For real-world Python development in today’s multi-language, multi-platform environment, Komodo is not just the best choice in terms of overall design and features, it’s simply the most practical choice.


Michael Churchman is a Fixate IO contributor. He started as a scriptwriter, editor, and producer during the anything-goes early years of the game industry. He spent much of the ‘90s in the high-pressure bundled software industry, where the move from waterfall to faster release was well under way, and near-continuous release cycles and automated deployment were already de facto standards.


Discussion

Click on a tab to select how you'd like to leave your comment

Leave a Comment

Your email address will not be published. Required fields are marked *

%d bloggers like this: