Message255042
I don't like the idea of [x] flashing quit instead of closing. This patch, on top of the one for #24455, may not be perfect, but the two are definite improvements. Unless I see something critically bad first, I want them in the upcoming releases. Mark claims that his second patch for #15347 improves behavior for no subprocess. But that was without this patch.
There is one situation not mentioned that I know is still glitchy. Debug a program with input(prompt). Run up to and including that line. While the program is waiting for input, close with [x]. The shell prints '[DEBUG OFF]' after the prompt and '>>> ' on the next line. But that is a fake prompt in that a statement entered will not be executed, but will be seen as the response to the pending input().
While there is a pending input (or any other blocked statement), the [Quit] button is disabled. The close method should detect this 'program executing' condition and ask whether to kill it, just as if one tries to close IDLE under the same condition.
I am leaving this open, at least for now, at least for this. |
|
Date |
User |
Action |
Args |
2015-11-21 05:26:07 | terry.reedy | set | recipients:
+ terry.reedy, roger.serwy, asvetlov, markroseman, THRlWiTi, python-dev, jimbo1qaz |
2015-11-21 05:26:07 | terry.reedy | set | messageid: <1448083567.55.0.279523345502.issue15348@psf.upfronthosting.co.za> |
2015-11-21 05:26:07 | terry.reedy | link | issue15348 messages |
2015-11-21 05:26:07 | terry.reedy | create | |
|