[issue41413] IDLE: exit at input() prompt is not complete

[Terry J. Reedy]

Terry J. Reedy  added the comment:

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.

--
nosy: +taleinat

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue41413] IDLE: exit at input() prompt is not complete

[Terry J. Reedy]

Terry J. Reedy  added the comment:

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.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue41413] IDLE: exit at input() prompt is not complete

[Irv Kalb]

Irv Kalb  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  wrote:
> 
> 
> Terry J. Reedy  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 
> 
> ___
>

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue41413] IDLE: exit at input() prompt is not complete

[Terry J. Reedy]

Terry J. Reedy  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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com