Terry, I don't understand your point clear. Using IDLE without subprocess has been deprecated in 3.4 (see http://bugs.python.org/issue16123) and will be removed only in 3.5.
On Thu, Jan 17, 2013 at 10:29 AM, Terry Reedy <[email protected]> wrote: > 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 > > > _______________________________________________ > IDLE-dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/idle-dev -- Thanks, Andrew Svetlov _______________________________________________ IDLE-dev mailing list [email protected] http://mail.python.org/mailman/listinfo/idle-dev
