(original) (raw)

> It's a lot to type (27 characters).

True. Personally I have a shortcut in my IDE (Sublime) so I when I type "pdb" -> TAB it auto completes it.

> Python linters (e.g. flake8 \[1\]) complain about this line because it contains two statements. Breaking the idiom up into two lines further complicates the use of the debugger,

I see this more as an advantage. After all a pdb line is "temporary" and you never want to commit it. When you do it is by accident so you want it to be more noticeable. I can configure my IDE to use flake8 and highlight the pdb line for me so that I can immediately see it because it's not PEP-8 compliant. I can have a GIT commit hook which checks there's no "pdb.set\_trace()" in the files I'm committing:
https://github.com/giampaolo/psutil/blob/master/.git-pre-commit#L93-L96
Somehow I think debug() would make this a bit harder as it's more likely a "debug()" line will pass unnoticed.
For this reason I would give a -1 to this proposal.

> It ties debugging directly to the choice of pdb. There might be other debugging options, say if you're using an IDE or some other development environment.

Personally I would find it helpful if there was a hook to choose the default debugger to use on "pdb.set\_trace()" via .pdbrc or PYTHONDEBUGGER environment variable or something.
I tried (unsuccessfully) to run ipdb on "pdb.set\_trace()", I gave up and ended up emulating auto completion and commands history with this:
https://github.com/giampaolo/sysconf/blob/master/home/.pdbrc.py


On Wed, Sep 6, 2017 at 9:14 AM, Barry Warsaw <barry@python.org> wrote:
I’ve written a PEP proposing the addition of a new built-in function called debug(). Adding this to your code would invoke a debugger through the hook function sys.debughook().

Like the existing sys.displayhook() and sys.excepthook(), you can change sys.debughook() to point to the debugger of your choice. By default it invokes pdb.set\_trace().

With this PEP instead of:

foo()
import pdb; pdb.set\_trace()
bar()

you can write:

foo()
debug()
bar()

and you would drop into the debugger after foo() but before bar(). More rationale and details are provided in the PEP:

https://www.python.org/dev/peps/pep-0553/

Unlike David, but like Larry, I have a prototype implementation:

https://github.com/python/cpython/pull/3355

Cheers,
\-Barry

P.S. This came to me in a nightmare on Sunday night, and the more I explored the idea the more it frightened me. I know exactly what I was dreaming about and the only way to make it all go away was to write this thing up.

\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_
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/g.rodola%40gmail.com




--
Giampaolo - http://grodola.blogspot.com