VS Code's Python debugger works through the Debug Adapter Protocol (DAP) — a standardised interface that separates the editor's debugging UI from the language-specific debugging logic. When you start a debug session for Python, VS Code launches a debug adapter that communicates with Python's built-in debugging hooks (sys.settrace and sys.setprofile). These hooks allow Python to call a function of your choice before executing each line — which is how the debugger intercepts execution at breakpoints.

This architecture means the VS Code debugger UI is the same regardless of language. Once you know how to use it for Python, the same panels, buttons, and concepts apply when you later debug JavaScript, or any other language VS Code supports.

Internally, VS Code stores breakpoints as line numbers in a file path. When the debug adapter starts a session, it communicates these to Python's trace function, which intercepts execution before each line and checks whether a breakpoint is registered for that line in that file. If yes, it suspends execution and notifies VS Code, which then updates the UI — highlighting the line, populating the Variables panel, and waiting for a step command.

This interception has a small performance cost: code running under a debugger is measurably slower than code running normally. For the programs you write in Grade 9, this is imperceptible. For large production programs, it can matter.

The launch.json configuration also supports more advanced options: passing command-line arguments to your program, setting environment variables, specifying a working directory, or attaching to an already-running process rather than launching a new one. For Flask applications, the configuration looks slightly different — you launch the Flask development server under the debugger rather than a standalone Python file. This is covered in the web development section of the knowledge base.

The Call Stack panel shows the current state of the call stack — one entry per active function call, from the outermost at the bottom to the current frame at the top. You can click on any frame in the Call Stack panel to inspect the variables in that frame. This is how you move between frames during debugging: clicking on a stack frame in the panel switches the Variables panel to show that frame's local variables instead of the current frame's.

This is the interactive version of the multi-frame traceback you read in the error messages article. Where the traceback is a printed snapshot of the call stack at the moment of a crash, the Call Stack panel is a live, navigable view of the same structure while the program is paused. You can move up and down the stack, reading each frame's variables, to understand how a particular state came to exist.

The four controls map directly to the granularity of control available through Python's tracing hooks. Step Over tells the debug adapter to advance one bytecode instruction at the current scope level. Step Into tells it to advance one instruction at any scope level, including descending into called functions. Step Out tells it to run until the current frame is popped from the stack and execution returns to the calling frame. Continue disables per-line interception entirely until a breakpoint is hit.

VS Code also supports Run to Cursor (right-click any line → Run to Cursor), which temporarily sets a one-time breakpoint at the clicked line, continues execution, and then removes the breakpoint after pausing. This is faster than setting and removing a breakpoint manually when you want to jump to a specific line once.

This worked example illustrates a general principle: the most useful moment to inspect a variable is just before it is passed to a function that crashes. The crash site is inside the function, but the root cause is in the data being passed in. Setting the breakpoint before the function call and checking the arguments in the Variables panel is faster than trying to reason about the crash from the error message alone.

This is the technique professionals call narrowing the problem: identify the boundary between where data is correct and where it is wrong, then inspect that boundary. The debugger makes boundary inspection fast and precise.

VS Code also supports logpoints — a variant of breakpoints that do not pause execution but instead print a message to the Debug Console when reached. Right-click in the gutter and choose Add Logpoint. In the message box, you can embed expressions in curly braces: Iteration {i}: total is {total}. VS Code evaluates the expressions and prints the result each time the line is reached.

Logpoints are a non-invasive alternative to adding print() statements: they produce output without modifying your code, and they are automatically removed when you stop the debug session. For programs that are difficult to pause mid-execution (web servers, event-driven programs), logpoints are often more practical than breakpoints.

The choice between print() and a debugger has a long history in programming culture. Unix-era programmers often prefer print() debugging (sometimes called printf debugging after C's print function) for its speed and portability — it works anywhere, even in production systems where attaching a debugger is not possible. Debugger advocates point out that print() requires you to know what to look for in advance, while a debugger lets you explore freely.

The practical answer, used by most working programmers, is both — whichever is faster for the specific problem at hand. The important thing is having both available and knowing what each one is good for. Programmers who only know print() are slower on complex bugs; programmers who only use the debugger sometimes reach for a powerful tool when a single print() would have solved it in ten seconds.