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

[Barry Warsaw]

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.

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 273 bytes
Desc: Message signed with OpenPGP
URL: <http://mail.python.org/pipermail/python-dev/attachments/20170907/3a80e8d6/attachment.sig>