[Idle-dev] Fwd: atexit handler in IDLE?

Terry Reedy tjreedy at udel.edu
Thu Jan 17 09:29:04 CET 2013


On 1/16/2013 9:47 PM, Steve Spicklemire wrote:
> So how dumb is this? For what it's worth... it works for me.

Only on 2.x ;-)
>
> -steve
>
> aluminum:idlelib steve$ diff -C3  run_orig.py run_new.py
> *** run_orig.py	 2013-01-16 15:31:08.000000000 -0700
> --- run_new.py	 2013-01-16 15:30:47.000000000 -0700
> ***************
> *** 308,313 ****
> --- 308,316 ----
>                if jit:
>                    self.rpchandler.interp.open_remote_stack_viewer()
>            else:
> +             if hasattr(sys,'exitfunc') and sys.exitfunc:
> +                 sys.exitfunc()

In 3.x, the replacement of sys.exitfunc (deprecated since 2.4!) by 
atexit was completed (by removing it). So, this patch is a 'no go' for 
stdlib IDLE, even for 2.7. See alternate patch idea below.

>                flush_stdout()
>
>        def interrupt_the_server(self):
>
>
> On Jan 16, 2013, at 9:17 AM, Roger Serwy wrote:
>
>> Hi Steve,
>>
>> IDLE's subprocess never actually exits, so the atexit handler will not be called. Forcing an exit with sys.exit() will be caught and the subprocess will still not exit.

At one time RESTART, either from the menu or from the editor, starting 
new subprocess -- at least on Windows xp. After a few seconds, the old 
subprocess disappeared from the Task Manager process listing. That is, 
until a change somewhere disabled process cleanup and zombie process 
accumulated. We switched to subprocess after that. I believe this was 
done in all versions, including 2.7.3.

Now, on 3.3 Win 7, the subprocess process line, with image name 
'python2.exe' remains and only the description 'pythonw' disappears and 
reappears.

I tried adding raise SystemExit to your code to see if that would force 
atexit processing. Unfortunately, not. It seems to be just caught like 
anything else. It seems we have succeeded in making it harder to exit 
IDLE without explicitly closing it.

SystemExit causes the normal interactive interpreter to exit.
'''
  exception SystemExit
     This exception is raised by the sys.exit() function. When it is not 
handled, the Python interpreter exits; no stack traceback is printed.'''

  One could argue that not closing at the subprocess (when there is one, 
as is the default) is a bug. Keeping IDLE itself up to receive the 
results of exit processing is good. In this sense, it is like a command 
window that can run python multiple times and receives exit output. The 
fact that RESTART now reuses the subprocess instead of a new one should 
be an invisible implementation detail. (Pasting Steve's code + 
systemexit 'works', but one has to look quick to see "OK..." before the 
window disappears. Adding a time delay helps.)

This issue is related to http://bugs.python.org/issue5492
The difference is that quit() and exit() ask whether or not to go ahead, 
and when they do, they close both processes. But atexit is still not 
triggered, so that is similar.

>> I suggest filing a bug at bugs.python.org.

I think the issue should be that raising SystemExit in user code should 
close the user subprocess, triggering atexit processing, while keeping 
the gui process, which would then do a real restart with a new user 
process. I may do it later today.

-- 
Terry Jan Reedy



More information about the IDLE-dev mailing list