This is probably related to earlier problems with running IDLE on MacOS Catalina:

Environment:

MacOS Catalina:  10.15.5
Python: 3.7.3
IDLE: 3.7.3

Steps to reproduce:

- Open IDLE, create a new file.  (Can reopen this file again for subsequent tests.)

- Code can consist of a single line:

dontCare = input('While this prompt for input is up, press Command q: ')

- Save and run

- When you see the prompt, press Command q to quit.

- See correct dialog box:  Your program is still running!  Do you want to kill it?

- Press OK.

Results:

- Python program quits.  Source file window closes. IDLE is left in an "unstable" state with only the IDLE menu option available.

At this point, any attempt to do anything with IDLE crashes IDLE, and shows a Mac system dialog box:

IDLE quit unexpectedly.  Click Reopen to open the application. Click Report to .....


Note:  This is not a huge deal because I have to restart IDLE anyway because of a bug 38946, which does not allow me to allow me to double click on a Python file if IDLE is already running.  But I thought this new information might help track things down.



I have run in to this because I am correcting many student's homework files, where I ask them to build a loop where they ask the user for information, do some processing, and generate output with that information.  Then the loop goes around again and asks for input again.  I want to quit the application at that point, but I always end up crashing IDLE.

Thanks for the report. Actually this behavior is not specific to running IDLE on macOS, it's also reproducible on Linux and on all current versions of IDLE.

Simpler test.

Open IDLE Shell (only) from icon or (preferably) terminal.
>>> input()
   # Close IDLE without giving input with Window (X), File => exit, or Control/Command-Q.
Click OK in "Your program is still running" box (from PyShell)

On Windows, IDLE closes apparently cleanly, but Task Manager shows that (at least usually) the IDLE process moves from Apps to Background processes, with label 'Python x.y.z Shell', where it remains as an inaccessible 20 mb zombie until [End Task]ed.  This is not normal.

On macOS Mohave, the Shell window and IDLE part of the top menubar disappear, but the Apple part remains with the apple and program name entry ("IDLE" or "Python" depending on whether started from icon or Terminal).  I presume this is the equivalent of Python becoming a background process, except that Apple keeps a visible link to it.  If I start IDLE in Terminal with trailing &, there are initially two processes, and the first remains along with the Apple menu.

Under the IDLE/Python menu item, About and Preferences still bring up the corresponding dialogs, which worked as far as I tested.  This confirms that the IDLE process is still alive. A couple of times, Quit (Command-Q) worked to quit/crash python, and Segmentation Fault appeared in Terminal once.  Later, Quit did not work and I had to use (apple)=> Force Quit.

The trivial solution is to not close with input pending.  First, either hit Enter to let the user code run or end-of-file (default ^D) to kill it.  A corresponding patch could enforce this with a message to enter or kill before closing.

However, I believe the issue is that PyShell.readline uses a nested tk mainloop() as a control mechanism.  Four callbacks, including eof_callback, call quit() to exit the nested mainloop and finish readline.  But the callback has to finish and be pulled off the stack first.  Three of the callbacks return immediately after 'quit()'.  However, PyShell.close continues closing before readline continues.

When I replaced pyshell line  1016
        return EditorWindow.close(self)
with
        root.after(1, EditorWindow.close self)
the bug disappears.  The opens a time gap between PyShell.close and EditorWindow.close that allows readline to return '', signalling end-of-file.

This change also works on my Mac, except that I have to say 'yes' twice to close.
Irv, please try this replacement on your system.

I have tried the test that Terry outlined (from double clicking on the IDLE icon), and I can confirm that I get the exact same results.  In the menu bar, I see just the Apple icon and "IDLE".  The items in the IDLE menu work (About IDLE and Preferences).  At that point, I have to force quit.

I found the pyshell.py file and the line that you suggested changing.  I can make the change but when I go to save, I get a permissions error and cannot save the file.

Irv

> On Jul 27, 2020, at 7:44 PM, Terry J. Reedy <report@bugs.python.org> wrote:
> 
> 
> Terry J. Reedy <tjreedy@udel.edu> added the comment:
> 
> Simpler test.
> 
> Open IDLE Shell (only) from icon or (preferably) terminal.
>>>> input()
>   # Close IDLE without giving input with Window (X), File => exit, or Control/Command-Q.
> Click OK in "Your program is still running" box (from PyShell)
> 
> On Windows, IDLE closes apparently cleanly, but Task Manager shows that (at least usually) the IDLE process moves from Apps to Background processes, with label 'Python x.y.z Shell', where it remains as an inaccessible 20 mb zombie until [End Task]ed.  This is not normal.
> 
> On macOS Mohave, the Shell window and IDLE part of the top menubar disappear, but the Apple part remains with the apple and program name entry ("IDLE" or "Python" depending on whether started from icon or Terminal).  I presume this is the equivalent of Python becoming a background process, except that Apple keeps a visible link to it.  If I start IDLE in Terminal with trailing &, there are initially two processes, and the first remains along with the Apple menu.
> 
> Under the IDLE/Python menu item, About and Preferences still bring up the corresponding dialogs, which worked as far as I tested.  This confirms that the IDLE process is still alive. A couple of times, Quit (Command-Q) worked to quit/crash python, and Segmentation Fault appeared in Terminal once.  Later, Quit did not work and I had to use (apple)=> Force Quit.
> 
> The trivial solution is to not close with input pending.  First, either hit Enter to let the user code run or end-of-file (default ^D) to kill it.  A corresponding patch could enforce this with a message to enter or kill before closing.
> 
> However, I believe the issue is that PyShell.readline uses a nested tk mainloop() as a control mechanism.  Four callbacks, including eof_callback, call quit() to exit the nested mainloop and finish readline.  But the callback has to finish and be pulled off the stack first.  Three of the callbacks return immediately after 'quit()'.  However, PyShell.close continues closing before readline continues.
> 
> When I replaced pyshell line  1016
>        return EditorWindow.close(self)
> with
>        root.after(1, EditorWindow.close self)
> the bug disappears.  The opens a time gap between PyShell.close and EditorWindow.close that allows readline to return '', signalling end-of-file.
> 
> This change also works on my Mac, except that I have to say 'yes' twice to close.
> Irv, please try this replacement on your system.
> 
> ----------
> title: At prompt for input(), pressing Command q kills IDLE -> IDLE: exit at input() prompt is not complete
> 
> _______________________________________
> Python tracker <report@bugs.python.org>
> <https://bugs.python.org/issue41413>
> _______________________________________
>

IRv, please, please, snip the message you respond to when replying by email instead of with a browser.

I am guessing that you or someone installed python as root/admin and you are working as non-root. 

I will try to figure out why the change results in the 'running' box appearing twice instead of just once, and if a fix is possible that does not make this happen.  But I have noticed on other close issues that close is at least sometimes called more than once.  The shutdown system has multiple patches and is delicate to change, and not unittested, which would be non-trivial.  The peculiarily of this issue is that it is the initial idle process left running rather than the secondary user code execution process.

More specifically, why the change results the same box twice on Mac but not on Windows.  The previous double-save issue, worst on Mac, was #35379.