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

[Terry Reedy]

On 9/7/2017 12:52 PM, Barry Warsaw wrote:
> On Sep 7, 2017, at 07:46, Guido van Rossum <guido at python.org> wrote:
> 
>> Without following all this (or the PEP, yet) super exactly, does this mean you are satisfied with what the PEP currently proposes or would you like changes? It's a little unclear from what you wrote.
> 
> I’m also unsure whether Terry is good with the existing PEP or suggesting changes.

It seems to me that simplifying 'import pdb; pbd.set_trace()' to 
'breakpoint()' is not, in itself, justification for a new builtin. 
Rather, the justification is the possibility of invoking dbs other than 
pdb.  So I have been examining the feasibility of doing that, with 
IDLE's Idb + rpc + Debugger widget as a test case and example.  My 
conclusion: possible, but not as graceful as I would like.

In response to Barry's idea of PYTHONBREAKPOINTHOOK (default 
pdb.set_trace, and is 'HOOK' really needed), I examined further how 
IDLE's debugger is different and how the differences cause problems. 
Then a thought occurred to me: how about rewriting it as a pure tkinter 
GUI debugger, much more like pdb.  Call the module either gdb or tkdb. 
PYTHONBREAKPOINT=[package.].gdb.set_trace would then make more sense.

As with pdb, the UI would run in the same process as the debugger and 
user code.  No rpc setup needed.  No interference between the debug gui 
and the rest of IDLE (as sometimes happens now).  No need to pickle 
objects to display the bindings of global and local names. The reasons 
for separating user code from IDLE mostly do not apply to the debugger.

I would make it a single window with 2 panes, much like turtledemo, but 
with the turtle screen replaced with the GUI display.  (Try IDLE to see 
what that would look like now, or pull PR 2494 first to see it with one 
proposed patch.) Gdb should not be limited to running from IDLE but 
could be launched even when running code from the console.

After an initial version, the entry point could accept a list of 
breakpoint lines and a color mapping for syntax coloring.

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.

Breakpoint() should pass on other args. In particular, people who invoke 
gdb from within a tkinter program should be able to pass in the root 
widget, to be the master of the debug window.  This has to be done from 
within the user program, and the addition of breakpoint allows that, and 
makes running the gui with user code more feasible.
---

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.

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.

>> I think that's true for any IDE that has existing integrated debug capabilities. However for every IDE I would hope that calling breakpoint() will *also* break into the IDE's debugger. My use case is that sometimes I have a need for a *conditional* breakpoint where it's just much simpler to decide whether to break or not in Python code than it would be to use the IDE's conditional breakpoint facilities.
> 
> That certainly aligns with my own experience and expectations.  I guess I’m a fellow old dog. :)

-- 
Terry Jan Reedy