gh-82987: Stop on calling frame unconditionally for inline breakpoints#130493
Conversation
Co-authored-by: Tomas R. <[email protected]>
| @@ -0,0 +1 @@ | |||
| :mod:`pdb` will always stop on calling frames when inline breakpoints like :func:`breakpoint` or :func:`pdb.set_trace` are used, regardless of whether the module matches ``skip`` pattern. | |||
There was a problem hiding this comment.
This is probably worth a what's new entry.
There was a problem hiding this comment.
And a versionchange comment in the doc?
…fQlG.rst Co-authored-by: Irit Katriel <[email protected]>
| Added the *mode* argument. | ||
|
|
||
| .. versionchanged:: 3.14 | ||
| *skip* will be ignored if inline breakpoints like :func:`breakpoint` or :func:`set_trace` are used. |
There was a problem hiding this comment.
"if ... are used" could be misunderstood to mean that skip will always be ignored if those are ever used.
There was a problem hiding this comment.
Will changing it to "when ... are used" better? Or we should just use the longer version from the news entry?
There was a problem hiding this comment.
I think "when .. are used" has the same problem, as does the longer version from the news entry.
There was a problem hiding this comment.
Inline breakpoints like :func:`breakpoint` or :func:`pdb.set_trace` will always stop the program at calling frame, ignoring the ``skip`` pattern (if any).
Is this better?
There was a problem hiding this comment.
Then I'll use this for all 3 places :)
The testing code
seems a bit silly, but this is a real issue because we use the last instance of pdb for inline breakpoints now.
So if we instantiate a debugger like
p = pdb.Pdb(skip=["django.*"])somewhere, and we set an inline breakpoint in Django with an innocentbreakpoint(), it still won't stop inside Django modules.Overall I think it's reasonable that we always stop for inline breakpoints. The implementation I chose is to remove the condition for
opcodeevents which also makes sense. For now that event is exclusively used by inline breakpoints. Even if we add instruction level debugging in the future, I think the only useful command is "step instruction". It's hard to imagine instruction level breakpoints or something likeuntil instruction. Always trigger user function for opcode seems like an okay solution.