(original) (raw)

99% of the time I use a debugger I use pdb.set\_trace(). The pm() stuff is typically useful for debugging small, simple programs only -- complex programs likely hide the exception somewhere (after logging it) so there's nothing for pdb.pm() to look at. I think Barry is wisely focusing on just the ability to quickly and programmatically insert a breakpoint.

On Wed, Sep 6, 2017 at 10:00 AM, Nathaniel Smith <njs@pobox.com> wrote:

On Wed, Sep 6, 2017 at 7:39 AM, Barry Warsaw <barry@python.org> wrote:
>> On Tue, Sep 5, 2017 at 7:58 PM, Nathaniel Smith <njs@pobox.com> wrote:
>> This would also avoid confusion with IPython's very
\>> useful debug magic:
\>> https://ipython.readthedocs.io/en/stable/interactive/magics.html#magic-debug
\>> and which might also be worth stealing for the builtin REPL.
\>> (Personally I use it way more often than set\_trace().)
\>
\> Interesting. I’m not an IPython user. Do you think its %debug magic would benefit from PEP 553?

Not in particular. But if you're working on making debugger entry more
discoverable/human-friendly, then providing a friendlier alias for the
pdb.pm() semantics might be useful too?

Actually, if you look at the pdb docs, the 3 ways of entering the
debugger that merit demonstrations at the top of the manual page are:

pdb.run("...code...") # "I want to debug this code"
pdb.set\_trace() # "break here"
pdb.pm() # "wtf just happened?"

The set\_trace() name is particularly opaque, but if we're talking
about adding a friendly debugger abstraction layer then I'd at least
think about whether to make it cover all three of these.

\-n

\--
Nathaniel J. Smith -- https://vorpus.org
\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: https://mail.python.org/mailman/options/python-dev/guido%40python.org

--Guido van Rossum (python.org/\~guido)