Irv Kalb <i...@furrypants.com> added the comment:
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 <rep...@bugs.python.org> wrote:
>
>
> Terry J. Reedy <tjre...@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 <rep...@bugs.python.org>
> <https://bugs.python.org/issue41413>
> _______________________________________
>
----------
_______________________________________
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue41413>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
