On 9/7/2017 10:45 PM, Barry Warsaw wrote:
On Sep 7, 2017, at 16:19, Terry Reedy <tjre...@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
_______________________________________________
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
