Quick wins for a faster PC:
Scan for outdated or missing drivers - takes under a minuteDriver Scan →Clear out junk files and repair common Windows errorsFree Scan →Use breakpoint() to pause Python where you need to inspect live state; use pdb commands or python -m pdb to control a debugging session. For exceptions, choose a hook based on where the error occurs: sys.excepthook for uncaught main-thread exceptions, threading.excepthook for uncaught thread exceptions, and sys.unraisablehook for errors Python cannot propagate normally. If an exception has already happened and its traceback is available, use pdb.post_mortem() or pdb.pm().
How to pause Python at a breakpoint
Add breakpoint() on the line where you want execution to stop. By default, Python routes it through sys.breakpointhook() to pdb.set_trace(), opening the built-in debugger at that call site. Calling pdb.set_trace() directly is the explicit alternative. See the Python built-in functions reference and the pdb documentation.
At the (Pdb) prompt, enter a command and press Return. Common commands include:
| Command | What it does |
|---|---|
p expression |
Evaluates and prints an expression, such as p user_id. |
w |
Shows the current stack, helping locate the paused frame’s callers. |
n |
Runs the next line in the current function without stepping into a called function. |
s |
Steps into a function call. |
c |
Continues execution until another breakpoint or the program ends. |
To set breakpoints without editing the source, launch a script under the debugger:
#1 Best Overall
python -m pdb your_script.py
The debugger starts before normal execution, so you can enter breakpoint commands at the prompt. The pdb command set also supports breakpoints by source line or function, conditional and temporary breakpoints, ignore counts, and enabling or disabling breakpoints. Consult the pdb command reference for the command syntax.
How to choose and control a debugging approach
| Approach | When execution stops | Control and scope | Useful for |
|---|---|---|---|
breakpoint() or pdb.set_trace() |
At the call site during execution. | A source edit pauses the current process at a specific point. | Inspecting local variables, checking assumptions, then stepping or continuing. |
python -m pdb your_script.py |
Under debugger control from the start of the script. | Command-line session; source need not contain a breakpoint call. | Debugging startup behavior or setting breakpoints interactively. |
sys.breakpointhook() and PYTHONBREAKPOINT |
Whenever code calls breakpoint(). |
Process-wide breakpoint behavior, configurable through Python or the environment. | Disabling pauses or redirecting them to a debugger callable. |
| Exception hook | When an exception reaches that hook’s scope. | Scope depends on the hook: main flow, a thread, or an unraisable exception. | Reporting or routing uncaught errors. |
pdb.post_mortem() or pdb.pm() |
After an exception has been raised, using its traceback. | Interactive inspection of the frames captured by the traceback. | Diagnosing a failure after normal execution has already stopped or been caught. |
How to disable or redirect breakpoint()
The default sys.breakpointhook() checks PYTHONBREAKPOINT. An unset or empty value uses pdb.set_trace(); setting the variable to 0 makes the default hook do nothing:
Rank #2
PYTHONBREAKPOINT=0 python your_script.py
This environment-variable syntax is for shells that support the NAME=value command form. In other environments, set PYTHONBREAKPOINT in the process environment before starting Python.
A dotted callable value can redirect breakpoint() to another debugger function. The callable is resolved when the hook is invoked. If code replaces sys.breakpointhook() programmatically, that replacement takes precedence over the environment variable. The behavior and configuration are documented in the built-in functions reference.
Which Python exception hook should you customize?
These hooks handle different cases; choose by the path through which the exception escapes. They are for diagnostics such as reporting or logging, not a substitute for try/except where the program can recover. The sys reference and threading reference describe their scopes.
| Hook | Use it for | Scope |
|---|---|---|
sys.excepthook |
An uncaught exception in the main execution path. | Uncaught main-flow exceptions before the interpreter’s normal termination report. |
threading.excepthook |
An exception escaping Thread.run(). |
Uncaught exceptions from threads created with threading. |
sys.unraisablehook |
An exception Python cannot propagate through the normal exception mechanism. | Unraisable exceptions, which are distinct from ordinary uncaught exceptions. |
When wrapping a default hook, preserve the original hook and call it if you still want Python’s standard reporting. For example, a main-flow wrapper can log first and then delegate:
import sys
original_excepthook = sys.excepthook
def report_uncaught(exc_type, exc_value, traceback):
# Add application-specific logging here.
original_excepthook(exc_type, exc_value, traceback)
sys.excepthook = report_uncaught
This example covers only sys.excepthook; it does not install handlers for worker threads or unraisable exceptions. Customize those hooks separately when those error paths need distinct handling.
How to inspect an exception after it happened
If an exception handler has access to the active exception, call pdb.pm() to enter post-mortem debugging. If you have the traceback or exception object, pass it to pdb.post_mortem(). For example:
Best Value
import pdb
try:
run_task()
except Exception:
pdb.pm()
raise
The debugger opens on the traceback so you can inspect the failing frame and its local state. In this example, raise re-raises the exception after you leave the debugger; remove or change that behavior only if the surrounding application has an intentional recovery path. The APIs are described in the pdb documentation.
Python 3.14 breakpoint behavior
Python 3.14 documents that inline breakpoint() and pdb.set_trace() stop at the calling frame regardless of the debugger’s skip pattern. This matters if you use skip patterns to avoid stepping through selected modules: an explicit inline breakpoint still stops where it is called. Check the Python 3.14 pdb documentation when relying on this behavior; it is version-specific.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.

