This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author terry.reedy
Recipients THRlWiTi, asvetlov, jimbo1qaz, markroseman, python-dev, roger.serwy, terry.reedy
Date 2015-11-21.05:26:07
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1448083567.55.0.279523345502.issue15348@psf.upfronthosting.co.za>
In-reply-to
Content
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.
History
Date User Action Args
2015-11-21 05:26:07terry.reedysetrecipients: + terry.reedy, roger.serwy, asvetlov, markroseman, THRlWiTi, python-dev, jimbo1qaz
2015-11-21 05:26:07terry.reedysetmessageid: <1448083567.55.0.279523345502.issue15348@psf.upfronthosting.co.za>
2015-11-21 05:26:07terry.reedylinkissue15348 messages
2015-11-21 05:26:07terry.reedycreate