On 9/6/2017 10:42 AM, Barry Warsaw wrote:
I don’t think that’s a good idea. pdb is a thing, and that thing is the standard library debugger. I don’t think ‘pdb’ should be the term we use to describe a generic Python debugger interface. That to me is one of the advantages of PEP 553; it separates the act of invoking the debugging from the actual debugger so invoked.
I tried inserting import pdb; pdb.set_trace() into a simple file and running it from an IDLE editor. It works fine, using IDLE's shell as the console. (The only glitch is that (Pdb) q raises bdb.BdbQuit, which causes Shell to restart.) So I expect the proposed breakpoint() to work similarly.
IDLE has a gui-based debugger based on its Idb subclass of bdb.Bdb. I took a first look into whether IDLE could set it as the breakpoint() handler and concluded maybe, with some work, if some problems are solved.
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.
-- 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
