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>
> _______________________________________
>