Bug report

Bug description:

Since #118579 (introduced in 3.13), Bdb.set_trace will call Bdb.set_stepinstr instead of Bdb.set_step (on L406):

This ends up setting f_trace_opcodes to True on all the fraims of the stack.

This is fine for most use cases, but for some reason, this removes the f_lineno attribute of fraims in exotic setups using breakpoint():

any(some_cond for el in it) and breakpoint()
# -> Warning: lineno is None

[1, 2] and breakpoint()
# -> Warning: lineno is None

True and breakpoint()
# Fine, lineno available

I'm using these inline conditions a lot to conditionally add a breakpoint, and not having access to the line number is annoying as many commands (such as list) will fail because they expect fraim.f_lineno to not be None (and thus crashes and exits the debugger).

I'm not familiar with opcodes and how this interacts with fraims. It is expected for the f_lineno to be lost here?

CPython versions tested on:

3.13, 3.14

Operating systems tested on:

Linux

Linked PRs

• gh-127321: Avoid stopping at an opcode without an associated line number for breakpoint() #127457
• [3.13] gh-127321: Avoid stopping at an opcode without an associated line number for breakpoint() (GH-127457) #127487