> 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 <ba...@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
_______________________________________________ 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/archive%40mail-archive.com
