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

Guido van Rossum guido at python.org
Thu Sep 7 10:46:49 EDT 2017

On Wed, Sep 6, 2017 at 11:59 PM, Terry Reedy <tjreedy at udel.edu> wrote:

On 9/6/2017 6:45 PM, Barry Warsaw wrote:

On Sep 6, 2017, at 14:59, Terry Reedy <tjreedy at udel.edu> wrote:

Currently, the debugger is started in response to a menu seletion in the IDLE process while the python process is idle. One reason for the 'idle' requirement' is because when code is exec-uting, the loop that reads commands, executes them, and sends responses is blocked on the exec call. The IDLE process sets up its debugger window, its ends of the rpc channels, and commands to python process to set up Idb and the other ends of the channels. The challenge would be to initiate setup from the server process and deal with the blocked loop. Would the environment variable idea in the latest version of the PEP help you here? That seems to be a mechanism for users to convey which function to call. It does not simplify the function call chosen. pdb works because a) it is designed to be imported into and run in a user module and b) it uses the existing stdin and stdout streams to interact with the user. Idb, on the other hand, is designed to be import in idlelib.run, which is (almost) invisible to user code, and use a special channel to the GUI window. Having said that, I see a solution: before running user code, set things up as now, except do not start tracing and do not show the debugger window, but do set a run.idbready flag. Then breakpointhandler() can check the flag and start tracing either through idb or pdb.

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.

What makes breakpoint() less than super useful in IDLE is that IDLE already allows setting of persistent breakpoints on a line by right-clicking. Since they are not stored in the file, there is nothing to erase when one runs the code in Python directly.

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.

(Plus there's something about old dogs and new tricks, but I've forgotten exactly how that one goes. :-)

-- --Guido van Rossum (python.org/~guido) -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20170907/db2d58e0/attachment.html>

More information about the Python-Dev mailing list