Author roger.serwy
Recipients asvetlov, jimbo1qaz, roger.serwy, terry.reedy
Date 2012-10-08.07:09:04
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1349680145.73.0.596524654573.issue15348@psf.upfronthosting.co.za>
In-reply-to
Content
Attached is a patch against 3.4 to solve the issue.

The debugger was originally written for running IDLE without a subprocess. As a result, calls to idb.run() from Debugger.py would block until completed.  If .interacting == 1 then clicking "X" would not close the debugger window. Once the debugger finishes, the .interacting flag would reset to 0, which then allows for the Debugger.close() method to destroy the debugger window. Clicking "Quit" is one way to have the debugger finish.

When running *with* a subprocess, the idb.run() returns immediately, since it is using the IdbProxy object instead. As a consequence, the .interacting flag is also reset to 0 immediately despite the debugger still being active. Thus, clicking "X" would allow the debugger to close without properly stopping the debugger via clicking "Quit".

A useful side-effect of the interactive debugger being active is that the PyShell.executing flag is set to true. When the debugger stops, the call to PyShell.endexecuting() from poll_subprocess() resets the .executing flag. The patch checks if PyShell's executing is true in order to prevent the Debugger Window from being closed by clicking "X". This makes the behavior is consistent with running the IDLE debugger without a subprocess.


When running IDLE without a subprocess is fully removed (see issue16123), then maintaining the Debugger code will become simpler. Until then, testing against both code paths is necessary.
History
Date User Action Args
2012-10-08 07:09:05roger.serwysetrecipients: + roger.serwy, terry.reedy, asvetlov, jimbo1qaz
2012-10-08 07:09:05roger.serwysetmessageid: <1349680145.73.0.596524654573.issue15348@psf.upfronthosting.co.za>
2012-10-08 07:09:05roger.serwylinkissue15348 messages
2012-10-08 07:09:04roger.serwycreate