| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
Sorry, something went wrong.
Co-authored-by: Tomas R. <tomas.roun8@gmail.com>
| @@ -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.
Sorry, something went wrong.
There was a problem hiding this comment.
And a versionchange comment in the doc?
Sorry, something went wrong.
There was a problem hiding this comment.
Done
Sorry, something went wrong.
…fQlG.rst Co-authored-by: Irit Katriel <1055913+iritkatriel@users.noreply.github.com>
| 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.
Sorry, something went wrong.
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?
Sorry, something went wrong.
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.
Sorry, something went wrong.
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?
Sorry, something went wrong.
There was a problem hiding this comment.
Yes.
Sorry, something went wrong.
There was a problem hiding this comment.
Then I'll use this for all 3 places :)
Sorry, something went wrong.
| Back | FazBrowse Home | New Git URL |
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 innocent breakpoint(), 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 opcode events 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 like until instruction. Always trigger user function for opcode seems like an okay solution.