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.
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
don’t even know what useful thing I’d set `db` to to mean “invoke pdb”. Please
don’t say “well, pdb will still be the default so you don’t have to set it to
anything” because that does kind of miss the point.
I also want to keep breakpoint() as generic as possible. I think doing so
allows it to be a nice API into whatever interesting and sophisticated
implementations folks can think up underneath it. So *if* you came up with a
cool thing that interpreted `db` in some special way, there should be a very
low barrier to providing that to your users, e.g.:
* pip install myfancymetadebugger
* put a snippet which sets sys.breakpointhook in your $PYTHONSTARTUP file
* profit!
That second item could be replaced with
export PYTHONBREAKPOINTHOOK=myfancymetadebugger.invoke
(hmm, does that mean the envar is getting more interesting?)
> Breakpoint() should pass on other args.
I strongly believe it should pass through *all* args.
> 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. There’s nothing fundamentally different with
multiple calls to breakpoint() today. If we care, we can provide a more
efficient/different API and make that the default. The machinery in PEP 553
can easily support that, but doing it is outside the scope of the PEP.
> 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.
Cheers,
-Barry
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ 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
