Ways to Improve the Debugger that Don't Require Deep CS Background or Understanding the Code

A common question that comes up is: I don't understand the code, and I am not a programmer, but I'd like to help somehow.

Sponsor the project

You can sponsor the project. Open-source software is one of the few places where people take for granted that you can ask a professional for work and get it for free. I hear a lot: "My time is valuable, so I can't commit to doing any work on your project". Or: "Your code is too involved and I am a novice, so would you do this thing that I happen to need or want to see happen?"

If this were not software, one would expect to pay someone else for doing something one desires, even if that thing has a benefit to an entire community. For example, beautify the area around your house. Do you say to a gardener: The hedge or garden that you planted is so exotic, and I am a novice, so would you do such and such for free? It would benefit those who pass by on the street."

User Documentation

Write a Beginner's Guide

A beginner's guide to using this debugger could be added to https://python3-trepan.readthedocs.io/en/latest/. This could be its own document, if you like.

Describe Underlying Python Debugging Capabilities

Traditionally, Python debugging uses this weird debugging pattern where one typically modifies the source code to pull in the debugger at the point it is needed. This is done due ot the primitiveness of CPython debugging. Debugging source code incurs overhead. By loading the debugger late, this overhead is avoided until it is needed.

Describe Methods of using the debugger to avoid slowness.

And that leads us to describing the debugging model that Python uses. Python is event callback-driven. Show ways to use the debugger that avoid the necessary slowness that occurs. (Or find ways that trepan3k can implement setting breakpoints and step in, step out, step over faster. Or use less overhead.)

Given that often the source code needs to be modified, there are better and worse ways to do this. For example, I often code in

if some_complex_condition_is_met:
   breakpoint()

instead of:

breakpoint()

In the latter, I might have to continue many, many times before I reach the problem.

Or if some expression is raising a run-time error. I may modify the code as:

try:
   python_expression_that_triggers.an_error[sometimes]
except:
   breakpoint()