On 9/7/2017 12:52 PM, Barry Warsaw wrote:
On Sep 7, 2017, at 07:46, Guido van Rossum <gu...@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
_______________________________________________
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
