PCAP Strings Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✓

  Step 1: Start the pdb debugger. Step 2: Run the script. Step 3: Step through the code. Step 4: Inspect variables. Step 5: Exit the debugger.

  Why this is correct

  Correct. This is the only valid sequence: you must first launch pdb (via `python -m pdb script.py` or a `pdb.set_trace()` call), then issue the debugger's `run`/`continue` command to start or resume execution. Only after the program is actually running can you step line-by-line with `n` (next) or `s` (step into), inspect the current frame's variables with `p`, `pp`, or `display`, and finally quit the debugging session with `q` or `exit`. This order guarantees that the target code and its runtime state exist before you attempt to interact with them.

• ✗

  Step 1: Start the pdb debugger. Step 2: Inspect variables. Step 3: Step through the code. Step 4: Run the script. Step 5: Exit the debugger.

  Why it's wrong here

  Incorrect because you attempt to inspect variables immediately after starting pdb but before the script has been executed. At that point the debugger is sitting at the initial prompt (or at a `set_trace()` call before the relevant lines), so none of the script's local variables have been assigned yet; `p some_var` would raise a `NameError` or show only an undefined name. You must first issue the `run` command to populate the frame with actual data, and then stepping through the code will bring you to points where variables exist for inspection.

• ✗

  Step 1: Run the script. Step 2: Start the pdb debugger. Step 3: Step through the code. Step 4: Inspect variables. Step 5: Exit the debugger.

  Why it's wrong here

  Incorrect because running the script before starting pdb means the interpreter executes your code normally, without any debugger attached, so it will run to completion or crash before you ever get an interactive `(Pdb)` prompt. Starting pdb must happen before execution (e.g., `python -m pdb script.py` or inserting `breakpoint()`/`pdb.set_trace()`), otherwise you have no chance to set breakpoints, step through frames, or inspect the live call stack. Merely running the script first produces a finished process, not a debuggable one.

• ✗

  Step 1: Start the pdb debugger. Step 2: Step through the code. Step 3: Run the script. Step 4: Inspect variables. Step 5: Exit the debugger.

  Why it's wrong here

  Incorrect because `step` (or `next`) requires a currently active execution frame, but immediately after starting pdb no program has been run yet. The debugger is waiting in its command loop with no loaded user code, so issuing `step` will typically produce an error like `*** 'step' not allowed here` or simply do nothing. You must first execute the script with `run`/`continue` to reach the first stop point (the first line or a breakpoint), and only then can stepping commands advance through the code frame by frame.

Go deeper

Related to this question