[Python-Dev] PEP 553: Built-in debug()

[Terry Reedy]

On 9/7/2017 10:45 PM, Barry Warsaw wrote:
> On Sep 7, 2017, at 16:19, Terry Reedy <tjreedy at udel.edu> wrote:
> 
>> I think breakpoint() should have a db= parameter so one can select a debugger in one removable line.  The sys interface is more useful for IDEs to change the default, possible with other args (like breakpoints and colors) bound to the callable.
> 
> I’m skeptical about that.  I think any particular user is going to overwhelmingly use the same debugger, so having to repeat themselves every time they want to enter the debugger is going to get tedious fast.  I know it would annoy *me* if I had to tell it to use pdb every time I wrote `breakpoint()`, and I’m almost never going to use anything else.

OK

> I’m also not sure what useful semantics for `db` would be.  E.g. what specifically would you set `db` to in order to invoke idle or tkdb (‘gdb’ would be an unfortunate name I think, given the popular existing GNU Debugger ;).

I will stick with tkdb until there is a shed to paint.

>> A somewhat separate point: the name breakpoint() is slightly misleading, which has consequences if it is (improperly) called more than once. While breakpoint() acts as a breakpoint, what it does (at least in the default pdb case) is *initialize* and start a *new* debugger, possibly after an import.  Re-importing a module is no big deal.  Replacing an existing debugger with a *new* one, and tossing away all defined aliases and breakpoints and Bdb's internal caches, is.  It is likely not what most people would want or expect.  I think it more likely that people will call breakpoint() multiple times than they would, for instance, call pdb.set_trace() multiple times.
> 
> Multiple calls to pdb.set_trace() is fairly common in practice today, so I’m not terribly concerned about it.

I am slightly surprised, but I guess if one does not set anything, one 
would not lose anything.

>> With a gui debugger, having one window go and another appear might be additionally annoying.  If the first window is not immediately GCed, having two windows would be confusing.  Perhaps breakpoint() could be made a no-op after the first call.
> 
> Your sys.breakpointhook could easily implement that, with a much better user experience than what built-in breakpoint() could do anyway.

Now that I know multiple breakpoint()s are likely, I definitely would.

-- 
Terry Jan Reedy