On 9/6/2017 6:45 PM, Barry Warsaw wrote:
On Sep 6, 2017, at 14:59, Terry Reedy <tjre...@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.idb_ready flag. Then breakpoint_handler() can
check the flag and start tracing either through idb or pdb.
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.
--
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
