From steve at spvi.com Wed Jan 16 13:50:53 2013 From: steve at spvi.com (Steve Spicklemire) Date: Wed, 16 Jan 2013 05:50:53 -0700 Subject: [Idle-dev] Fwd: atexit handler in IDLE? References: <24E53D14-FD57-4FE2-8763-99149773650B@spvi.com> Message-ID: Hello Idle-dev folks, I tried this on the python list, with no luck. ;-( I hate to bother you with a basic user question, but I'm not sure where else to go. Is there a better list for this? thanks, -steve Begin forwarded message: > From: Steve Spicklemire > Subject: atexit handler in IDLE? > Date: January 15, 2013 5:25:34 AM MST > To: python-list at python.org > Cc: Steve Spicklemire > > Hello Pythonistas! > > I'm trying to get this program, which works on the command line, to run correctly in the IDLE environment: > > import atexit > > print "This is my program" > > def exit_func(): > print "OK.. that's all folks!" > > atexit.register(exit_func) > > print "Program is ending..." > > > When I run this on the command line I see: > > This is my program > Program is ending... > OK.. that's all folks! > > When I run this in IDLE I see: > > This is my program > Program is ending... > > But the atexit handler is never called. ;-( > > I tried to fish through the IDLE source to see how the program is actually called, and I decided it looked like it was being invoked with with os.spawnv, but I'm not sure why this would defeat the atexit handler. Anybody know? I'd like to register such a function in my module, but I need it to work in IDLE so that students can easily use it. > > thanks! > -steve > > > From roger.serwy at gmail.com Wed Jan 16 17:17:30 2013 From: roger.serwy at gmail.com (Roger Serwy) Date: Wed, 16 Jan 2013 10:17:30 -0600 Subject: [Idle-dev] Fwd: atexit handler in IDLE? In-Reply-To: References: <24E53D14-FD57-4FE2-8763-99149773650B@spvi.com> Message-ID: <50F6D29A.9010006@gmail.com> 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. I suggest filing a bug at bugs.python.org. - Roger On 01/16/2013 06:50 AM, Steve Spicklemire wrote: > Hello Idle-dev folks, > > I tried this on the python list, with no luck. ;-( > > I hate to bother you with a basic user question, but I'm not sure where else to go. Is there a better list for this? > > thanks, > -steve > > Begin forwarded message: > >> From: Steve Spicklemire >> Subject: atexit handler in IDLE? >> Date: January 15, 2013 5:25:34 AM MST >> To: python-list at python.org >> Cc: Steve Spicklemire >> >> Hello Pythonistas! >> >> I'm trying to get this program, which works on the command line, to run correctly in the IDLE environment: >> >> import atexit >> >> print "This is my program" >> >> def exit_func(): >> print "OK.. that's all folks!" >> >> atexit.register(exit_func) >> >> print "Program is ending..." >> >> >> When I run this on the command line I see: >> >> This is my program >> Program is ending... >> OK.. that's all folks! >> >> When I run this in IDLE I see: >> >> This is my program >> Program is ending... >> >> But the atexit handler is never called. ;-( >> >> I tried to fish through the IDLE source to see how the program is actually called, and I decided it looked like it was being invoked with with os.spawnv, but I'm not sure why this would defeat the atexit handler. Anybody know? I'd like to register such a function in my module, but I need it to work in IDLE so that students can easily use it. >> >> thanks! >> -steve >> >> >> > _______________________________________________ > IDLE-dev mailing list > IDLE-dev at python.org > http://mail.python.org/mailman/listinfo/idle-dev From steve at spvi.com Thu Jan 17 03:47:47 2013 From: steve at spvi.com (Steve Spicklemire) Date: Wed, 16 Jan 2013 19:47:47 -0700 Subject: [Idle-dev] Fwd: atexit handler in IDLE? In-Reply-To: <50F6D29A.9010006@gmail.com> References: <24E53D14-FD57-4FE2-8763-99149773650B@spvi.com> <50F6D29A.9010006@gmail.com> Message-ID: So how dumb is this? For what it's worth... it works for me. -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() + 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. > > I suggest filing a bug at bugs.python.org. > > - Roger > > > On 01/16/2013 06:50 AM, Steve Spicklemire wrote: >> Hello Idle-dev folks, >> >> I tried this on the python list, with no luck. ;-( >> >> I hate to bother you with a basic user question, but I'm not sure where else to go. Is there a better list for this? >> >> thanks, >> -steve >> >> Begin forwarded message: >> >>> From: Steve Spicklemire >>> Subject: atexit handler in IDLE? >>> Date: January 15, 2013 5:25:34 AM MST >>> To: python-list at python.org >>> Cc: Steve Spicklemire >>> >>> Hello Pythonistas! >>> >>> I'm trying to get this program, which works on the command line, to run correctly in the IDLE environment: >>> >>> import atexit >>> >>> print "This is my program" >>> >>> def exit_func(): >>> print "OK.. that's all folks!" >>> >>> atexit.register(exit_func) >>> >>> print "Program is ending..." >>> >>> >>> When I run this on the command line I see: >>> >>> This is my program >>> Program is ending... >>> OK.. that's all folks! >>> >>> When I run this in IDLE I see: >>> >>> This is my program >>> Program is ending... >>> >>> But the atexit handler is never called. ;-( >>> >>> I tried to fish through the IDLE source to see how the program is actually called, and I decided it looked like it was being invoked with with os.spawnv, but I'm not sure why this would defeat the atexit handler. Anybody know? I'd like to register such a function in my module, but I need it to work in IDLE so that students can easily use it. >>> >>> thanks! >>> -steve >>> >>> >>> >> _______________________________________________ >> IDLE-dev mailing list >> IDLE-dev at python.org >> http://mail.python.org/mailman/listinfo/idle-dev > > _______________________________________________ > IDLE-dev mailing list > IDLE-dev at python.org > http://mail.python.org/mailman/listinfo/idle-dev From roger.serwy at gmail.com Thu Jan 17 07:44:14 2013 From: roger.serwy at gmail.com (Roger Serwy) Date: Thu, 17 Jan 2013 00:44:14 -0600 Subject: [Idle-dev] Fwd: atexit handler in IDLE? In-Reply-To: References: <24E53D14-FD57-4FE2-8763-99149773650B@spvi.com> <50F6D29A.9010006@gmail.com> Message-ID: <50F79DBE.6050707@gmail.com> IDLE implicitly runs a script as if you specified "-i" when using regular python from the command line. Perhaps this behavior needs to be documented. For what it's worth, this would make the exitfuncs run on the 3.x series: diff -r be8e6b81284e Lib/idlelib/run.py --- a/Lib/idlelib/run.py Wed Jan 09 19:00:26 2013 +0100 +++ b/Lib/idlelib/run.py Thu Jan 17 00:41:22 2013 -0600 @@ -381,6 +381,8 @@ if jit: self.rpchandler.interp.open_remote_stack_viewer() else: + import atexit + atexit._run_exitfuncs() flush_stdout() def interrupt_the_server(self): On 01/16/2013 08:47 PM, Steve Spicklemire wrote: > So how dumb is this? For what it's worth... it works for me. > > -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() > + > 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. >> >> I suggest filing a bug at bugs.python.org. >> >> - Roger >> >> >> On 01/16/2013 06:50 AM, Steve Spicklemire wrote: >>> Hello Idle-dev folks, >>> >>> I tried this on the python list, with no luck. ;-( >>> >>> I hate to bother you with a basic user question, but I'm not sure where else to go. Is there a better list for this? >>> >>> thanks, >>> -steve >>> >>> Begin forwarded message: >>> >>>> From: Steve Spicklemire >>>> Subject: atexit handler in IDLE? >>>> Date: January 15, 2013 5:25:34 AM MST >>>> To: python-list at python.org >>>> Cc: Steve Spicklemire >>>> >>>> Hello Pythonistas! >>>> >>>> I'm trying to get this program, which works on the command line, to run correctly in the IDLE environment: >>>> >>>> import atexit >>>> >>>> print "This is my program" >>>> >>>> def exit_func(): >>>> print "OK.. that's all folks!" >>>> >>>> atexit.register(exit_func) >>>> >>>> print "Program is ending..." >>>> >>>> >>>> When I run this on the command line I see: >>>> >>>> This is my program >>>> Program is ending... >>>> OK.. that's all folks! >>>> >>>> When I run this in IDLE I see: >>>> >>>> This is my program >>>> Program is ending... >>>> >>>> But the atexit handler is never called. ;-( >>>> >>>> I tried to fish through the IDLE source to see how the program is actually called, and I decided it looked like it was being invoked with with os.spawnv, but I'm not sure why this would defeat the atexit handler. Anybody know? I'd like to register such a function in my module, but I need it to work in IDLE so that students can easily use it. >>>> >>>> thanks! >>>> -steve >>>> >>>> >>>> >>> _______________________________________________ >>> IDLE-dev mailing list >>> IDLE-dev at python.org >>> http://mail.python.org/mailman/listinfo/idle-dev >> _______________________________________________ >> IDLE-dev mailing list >> IDLE-dev at python.org >> http://mail.python.org/mailman/listinfo/idle-dev From tjreedy at udel.edu Thu Jan 17 09:29:04 2013 From: tjreedy at udel.edu (Terry Reedy) Date: Thu, 17 Jan 2013 03:29:04 -0500 Subject: [Idle-dev] Fwd: atexit handler in IDLE? In-Reply-To: References: <24E53D14-FD57-4FE2-8763-99149773650B@spvi.com> <50F6D29A.9010006@gmail.com> Message-ID: 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 From steve at spvi.com Thu Jan 17 12:42:20 2013 From: steve at spvi.com (Steve Spicklemire) Date: Thu, 17 Jan 2013 04:42:20 -0700 Subject: [Idle-dev] Fwd: atexit handler in IDLE? In-Reply-To: <50F79DBE.6050707@gmail.com> References: <24E53D14-FD57-4FE2-8763-99149773650B@spvi.com> <50F6D29A.9010006@gmail.com> <50F79DBE.6050707@gmail.com> Message-ID: That would be awesome.... thanks for your help! -steve On Jan 16, 2013, at 11:44 PM, Roger Serwy wrote: > IDLE implicitly runs a script as if you specified "-i" when using regular python from the command line. Perhaps this behavior needs to be documented. > > For what it's worth, this would make the exitfuncs run on the 3.x series: > > diff -r be8e6b81284e Lib/idlelib/run.py > --- a/Lib/idlelib/run.py Wed Jan 09 19:00:26 2013 +0100 > +++ b/Lib/idlelib/run.py Thu Jan 17 00:41:22 2013 -0600 > @@ -381,6 +381,8 @@ > if jit: > self.rpchandler.interp.open_remote_stack_viewer() > else: > + import atexit > + atexit._run_exitfuncs() > flush_stdout() > > def interrupt_the_server(self): > > > > On 01/16/2013 08:47 PM, Steve Spicklemire wrote: >> So how dumb is this? For what it's worth... it works for me. >> >> -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() >> + >> 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. >>> >>> I suggest filing a bug at bugs.python.org. >>> >>> - Roger >>> >>> >>> On 01/16/2013 06:50 AM, Steve Spicklemire wrote: >>>> Hello Idle-dev folks, >>>> >>>> I tried this on the python list, with no luck. ;-( >>>> >>>> I hate to bother you with a basic user question, but I'm not sure where else to go. Is there a better list for this? >>>> >>>> thanks, >>>> -steve >>>> >>>> Begin forwarded message: >>>> >>>>> From: Steve Spicklemire >>>>> Subject: atexit handler in IDLE? >>>>> Date: January 15, 2013 5:25:34 AM MST >>>>> To: python-list at python.org >>>>> Cc: Steve Spicklemire >>>>> >>>>> Hello Pythonistas! >>>>> >>>>> I'm trying to get this program, which works on the command line, to run correctly in the IDLE environment: >>>>> >>>>> import atexit >>>>> >>>>> print "This is my program" >>>>> >>>>> def exit_func(): >>>>> print "OK.. that's all folks!" >>>>> >>>>> atexit.register(exit_func) >>>>> >>>>> print "Program is ending..." >>>>> >>>>> >>>>> When I run this on the command line I see: >>>>> >>>>> This is my program >>>>> Program is ending... >>>>> OK.. that's all folks! >>>>> >>>>> When I run this in IDLE I see: >>>>> >>>>> This is my program >>>>> Program is ending... >>>>> >>>>> But the atexit handler is never called. ;-( >>>>> >>>>> I tried to fish through the IDLE source to see how the program is actually called, and I decided it looked like it was being invoked with with os.spawnv, but I'm not sure why this would defeat the atexit handler. Anybody know? I'd like to register such a function in my module, but I need it to work in IDLE so that students can easily use it. >>>>> >>>>> thanks! >>>>> -steve >>>>> >>>>> >>>>> >>>> _______________________________________________ >>>> IDLE-dev mailing list >>>> IDLE-dev at python.org >>>> http://mail.python.org/mailman/listinfo/idle-dev >>> _______________________________________________ >>> IDLE-dev mailing list >>> IDLE-dev at python.org >>> http://mail.python.org/mailman/listinfo/idle-dev From andrew.svetlov at gmail.com Thu Jan 17 13:45:55 2013 From: andrew.svetlov at gmail.com (Andrew Svetlov) Date: Thu, 17 Jan 2013 14:45:55 +0200 Subject: [Idle-dev] Fwd: atexit handler in IDLE? In-Reply-To: References: <24E53D14-FD57-4FE2-8763-99149773650B@spvi.com> <50F6D29A.9010006@gmail.com> Message-ID: 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 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 > IDLE-dev at python.org > http://mail.python.org/mailman/listinfo/idle-dev -- Thanks, Andrew Svetlov From tjreedy at udel.edu Thu Jan 17 14:56:41 2013 From: tjreedy at udel.edu (Terry Reedy) Date: Thu, 17 Jan 2013 08:56:41 -0500 Subject: [Idle-dev] Fwd: atexit handler in IDLE? In-Reply-To: References: <24E53D14-FD57-4FE2-8763-99149773650B@spvi.com> <50F6D29A.9010006@gmail.com>

Message-ID: On 1/17/2013 7:45 AM, Andrew Svetlov wrote: > Terry, I don't understand your point clear. If you want anything from me, ask a specific question. > Using IDLE without subprocess has been deprecated in 3.4 (see > http://bugs.python.org/issue16123) and will be removed only in 3.5. I effectively wrote as if that option were already removed, as I did not discuss the single process case. With a single process, closing the user process without closing the gui process makes no sense. At it is, Roger is proposing to for atexit processing in the user process without closing it. -- Terry Jan Reedy From tjreedy at udel.edu Thu Jan 17 16:22:50 2013 From: tjreedy at udel.edu (Terry Reedy) Date: Thu, 17 Jan 2013 10:22:50 -0500 Subject: [Idle-dev] Fwd: atexit handler in IDLE? In-Reply-To: <50F79DBE.6050707@gmail.com> References: <24E53D14-FD57-4FE2-8763-99149773650B@spvi.com> <50F6D29A.9010006@gmail.com> <50F79DBE.6050707@gmail.com> Message-ID: On 1/17/2013 1:44 AM, Roger Serwy wrote: > IDLE implicitly runs a script from the editor window > as if you specified "-i" when using > regular python from the command line. Perhaps this behavior needs to be > documented. I agree, as part of documenting the behavior itself. It should be obvious to anyone who understands -i. That is why one can interactively poke around at the result of running the script and one reason I use IDLE to develop code. But many (most?) have never used -i from the command line and have not read the command line documentation carefully. That said, I wonder: does your proposed patch makes the IDLE behavior more, or less, like that of "python xxx -i"? If a file, such Steve's, is run like so, from the command line with -i, does atexit processing automatically happen before switching to interactive mode, or not? Perhaps one of you can test. If yes, then IDLE should do the same before it switches and prints the interactive '>>>' prompt. If not, then I think IDLE should not either. In the same circumstance, does ending the file with 'raise SystemExit' make any difference. In particular, if the answer above is No, is that answer changed? Does explicit SystemExit get printed as IDLE does now, or does it abort -i mode? As with the interpreter, atexit processing should not happen when running a statement entered in response to the prompt and a patch should not change this. My general idea is that we first match normal atexit behavior and be explicit about any deviations we decide on. > For what it's worth, this would make the exitfuncs run on the 3.x series: Only if there is no exception, even SystemExit, whereas at least the latter and probably any uncaught exception *should* trigger atexit. The doc says "Note: The functions registered via this module are not called when the program is killed by a signal not handled by Python, when a Python fatal internal error is detected, or when os._exit() is called." Termination by an exception that is not caught in user code (which *is* caught by the unwritten try: except: that prints a traceback) seems not included in the above (unless they internally trigger os._exit, but I am pretty sure not). In any case adding 1/0 to Steve's file and running from a command line would tell. In any case: "At normal program termination (for instance, if sys.exit() is called or the main module?s execution completes), all functions registered are called ..." I do not complete understand the following, or if we can imitate the behavior it specifies with the undocumented ._run_exitfuncs. "If an exception is raised during execution of the exit handlers, a traceback is printed (unless SystemExit is raised) and the exception information is saved. After all exit handlers have had a chance to run the last exception to be raised is re-raised." > diff -r be8e6b81284e Lib/idlelib/run.py This is current 3.4a0 (default branch) > --- a/Lib/idlelib/run.py Wed Jan 09 19:00:26 2013 +0100 > +++ b/Lib/idlelib/run.py Thu Jan 17 00:41:22 2013 -0600 > @@ -381,6 +381,8 @@ > if jit: > self.rpchandler.interp.open_remote_stack_viewer() > else: > + import atexit I assume below that actual patch does import at top of file. > + atexit._run_exitfuncs() As long as this works, it is a nice alternative to my idea of forcing atexit by actually exiting and restarting user process. The question is where and when to do it. See questions above and below. > flush_stdout() Below is the full code of the class Executive(object) method, with comments and possible changes, and a question. def runcode(self, code): global interruptable try: self.usr_exc_info = None interruptable = True try: exec(code, self.locals) finally: interruptable = False - except: #This bare except should be changed to an explicit 'except BaseException' (unless we decide that is wrong ;-) or rather 'except BaseException as e' (see below). The code comment below about even catching SystemExit, which is a BaseException, but not an Exception, makes the intention clear. + except BaseException as e: self.usr_exc_info = sys.exc_info() if quitting: exit() # quitting is global set False initially and True at 277, 347, 353. + atexit._run_exitfuncs() # perhaps this should be conditioned on isinstance(e, SystemExit) # but as noted above, I think not # even print a user code SystemExit exception, continue print_exception() jit = self.rpchandler.console.getvar( "<>") if jit: self.rpchandler.interp.open_remote_stack_viewer() else: + atexit._run_exitfuncs() flush_stdout() # The else block only runs if there is no exception in the exec statement. I am guessing that Executive is instantiated in the user process and that runcode runs usercode in the user process. Is runcode only used for running scripts? Or is it also used to run interactive statements? If the latter, does or could runcode know which, so atexit can be run in the former case but not the latter? In particular, registering an atexit function should not cause its immediate execution. -- Terry Jan Reedy From steve at spvi.com Thu Jan 17 22:44:20 2013 From: steve at spvi.com (Steve Spicklemire) Date: Thu, 17 Jan 2013 14:44:20 -0700 Subject: [Idle-dev] Fwd: atexit handler in IDLE? In-Reply-To: References: <24E53D14-FD57-4FE2-8763-99149773650B@spvi.com> <50F6D29A.9010006@gmail.com> <50F79DBE.6050707@gmail.com> Message-ID: <57FED75E-88BD-49D2-B69E-A07584389BA3@spvi.com> On Jan 17, 2013, at 8:22 AM, Terry Reedy wrote: > If a file, such Steve's, is run like so, from the command line with -i, does atexit processing automatically happen before switching to interactive mode, or not? Perhaps one of you can test. It appears to happen after you exit from interactive mode, at least on python 2.6,2.7,3.2 and 3.3. I'll have to wait to get to a computer to absorb the rest. I can't read all that on my phone! Thanks, Steve From tjreedy at udel.edu Fri Jan 18 12:59:51 2013 From: tjreedy at udel.edu (Terry Reedy) Date: Fri, 18 Jan 2013 06:59:51 -0500 Subject: [Idle-dev] Fwd: atexit handler in IDLE? In-Reply-To: <57FED75E-88BD-49D2-B69E-A07584389BA3@spvi.com> References: <24E53D14-FD57-4FE2-8763-99149773650B@spvi.com> <50F6D29A.9010006@gmail.com> <50F79DBE.6050707@gmail.com> <57FED75E-88BD-49D2-B69E-A07584389BA3@spvi.com> Message-ID: On 1/17/2013 4:44 PM, Steve Spicklemire wrote: > > On Jan 17, 2013, at 8:22 AM, Terry Reedy wrote: > >> If a file, such Steve's, is run like so, from the command line with -i, does atexit processing automatically happen before switching to interactive mode, or not? Perhaps one of you can test. > > It appears to happen after you exit from interactive mode, at least on python 2.6,2.7,3.2 and 3.3. > > I'll have to wait to get to a computer to absorb the rest. I can't read all that on my phone! This suggests to me that IDLE should run atexit stuff in the user process before is exits and before it RESTARTs. In the latter case, any atexit output will appear in the shell before the RESTART line. -- Terry Jan Reedy From steve at spvi.com Fri Jan 18 13:06:34 2013 From: steve at spvi.com (Steve Spicklemire) Date: Fri, 18 Jan 2013 05:06:34 -0700 Subject: [Idle-dev] Fwd: atexit handler in IDLE? In-Reply-To: References: <24E53D14-FD57-4FE2-8763-99149773650B@spvi.com> <50F6D29A.9010006@gmail.com> <50F79DBE.6050707@gmail.com> <57FED75E-88BD-49D2-B69E-A07584389BA3@spvi.com> Message-ID: <77873E06-908A-44F9-AB5F-D13F20703A73@spvi.com> That would be awesome if it could be done. At the moment my patch is working for me in 2.7.3 (which is all I need for the moment). I have to say... the deeper implications of one approach or another on IDLE as a whole are pretty much lost on me. ;-( It would be nice if this behavior could be incorporated into IDLE at some point, since I can't be sure my students will always be using (or have access to) my patched version. thanks, -steve On Jan 18, 2013, at 4:59 AM, Terry Reedy wrote: > On 1/17/2013 4:44 PM, Steve Spicklemire wrote: >> >> On Jan 17, 2013, at 8:22 AM, Terry Reedy wrote: >> >>> If a file, such Steve's, is run like so, from the command line with -i, does atexit processing automatically happen before switching to interactive mode, or not? Perhaps one of you can test. >> >> It appears to happen after you exit from interactive mode, at least on python 2.6,2.7,3.2 and 3.3. >> >> I'll have to wait to get to a computer to absorb the rest. I can't read all that on my phone! > > This suggests to me that IDLE should run atexit stuff in the user process before is exits and before it RESTARTs. In the latter case, any atexit output will appear in the shell before the RESTART line. > > -- > Terry Jan Reedy > > _______________________________________________ > IDLE-dev mailing list > IDLE-dev at python.org > http://mail.python.org/mailman/listinfo/idle-dev From steve at spvi.com Fri Jan 18 21:00:35 2013 From: steve at spvi.com (Steve Spicklemire) Date: Fri, 18 Jan 2013 13:00:35 -0700 Subject: [Idle-dev] Fwd: atexit handler in IDLE? In-Reply-To: <77873E06-908A-44F9-AB5F-D13F20703A73@spvi.com> References: <24E53D14-FD57-4FE2-8763-99149773650B@spvi.com> <50F6D29A.9010006@gmail.com> <50F79DBE.6050707@gmail.com> <57FED75E-88BD-49D2-B69E-A07584389BA3@spvi.com> <77873E06-908A-44F9-AB5F-D13F20703A73@spvi.com> Message-ID: <114319E6-2400-4DFF-81C3-462FAC54C707@spvi.com> A related question. Is it possible for my module to detect that it's being run under IDLE? Are there any clues in the environment that I could count on to tell? thanks! -steve On Jan 18, 2013, at 5:06 AM, Steve Spicklemire wrote: > That would be awesome if it could be done. > > At the moment my patch is working for me in 2.7.3 (which is all I need for the moment). > > I have to say... the deeper implications of one approach or another on IDLE as a whole are pretty much lost on me. ;-( > > It would be nice if this behavior could be incorporated into IDLE at some point, since I can't be sure my students will always be using (or have access to) my patched version. > > thanks, > -steve > > On Jan 18, 2013, at 4:59 AM, Terry Reedy wrote: > >> On 1/17/2013 4:44 PM, Steve Spicklemire wrote: >>> >>> On Jan 17, 2013, at 8:22 AM, Terry Reedy wrote: >>> >>>> If a file, such Steve's, is run like so, from the command line with -i, does atexit processing automatically happen before switching to interactive mode, or not? Perhaps one of you can test. >>> >>> It appears to happen after you exit from interactive mode, at least on python 2.6,2.7,3.2 and 3.3. >>> >>> I'll have to wait to get to a computer to absorb the rest. I can't read all that on my phone! >> >> This suggests to me that IDLE should run atexit stuff in the user process before is exits and before it RESTARTs. In the latter case, any atexit output will appear in the shell before the RESTART line. >> >> -- >> Terry Jan Reedy >> >> _______________________________________________ >> IDLE-dev mailing list >> IDLE-dev at python.org >> http://mail.python.org/mailman/listinfo/idle-dev > From tjreedy at udel.edu Fri Jan 18 22:06:29 2013 From: tjreedy at udel.edu (Terry Reedy) Date: Fri, 18 Jan 2013 16:06:29 -0500 Subject: [Idle-dev] Fwd: atexit handler in IDLE? In-Reply-To: <114319E6-2400-4DFF-81C3-462FAC54C707@spvi.com> References: <24E53D14-FD57-4FE2-8763-99149773650B@spvi.com> <50F6D29A.9010006@gmail.com> <50F79DBE.6050707@gmail.com> <57FED75E-88BD-49D2-B69E-A07584389BA3@spvi.com> <77873E06-908A-44F9-AB5F-D13F20703A73@spvi.com> <114319E6-2400-4DFF-81C3-462FAC54C707@spvi.com> Message-ID: On 1/18/2013 3:00 PM, Steve Spicklemire wrote: > A related question. Is it possible for my module to detect that it's > being run under IDLE? Are there any clues in the environment that I > could count on to tell? That is an interesting question. We try to make the answer 'no' as much as possible. But then I remembered (with 3.3, same on 2.7.3) >>> import sys >>> sys.stdin >>> 'idlelib' in str(sys.stdin) True The module may not always been a part of the representation, so I will not guarantee that for anything previous. There is also >>> sys.stdin.__module__ 'idlelib.rpc' and >>> 'idlelib' in sys.modules True I like this best. It is False in the standard interpreter on startup and I am sure not stdlib module imports idlelib. So as long as your program does not (and there is no reason to) it should be safe. -- Terry Jan Reedy From steve at spvi.com Fri Jan 18 22:19:36 2013 From: steve at spvi.com (Steve Spicklemire) Date: Fri, 18 Jan 2013 14:19:36 -0700 Subject: [Idle-dev] Fwd: atexit handler in IDLE? In-Reply-To: References: <24E53D14-FD57-4FE2-8763-99149773650B@spvi.com> <50F6D29A.9010006@gmail.com> <50F79DBE.6050707@gmail.com> <57FED75E-88BD-49D2-B69E-A07584389BA3@spvi.com> <77873E06-908A-44F9-AB5F-D13F20703A73@spvi.com> <114319E6-2400-4DFF-81C3-462FAC54C707@spvi.com> Message-ID: Thanks much! That's a very helpful answer. I'll check it! thanks, -steve On Jan 18, 2013, at 2:06 PM, Terry Reedy wrote: > On 1/18/2013 3:00 PM, Steve Spicklemire wrote: >> A related question. Is it possible for my module to detect that it's >> being run under IDLE? Are there any clues in the environment that I >> could count on to tell? > > That is an interesting question. We try to make the answer 'no' as much as possible. But then I remembered (with 3.3, same on 2.7.3) > > >>> import sys > >>> sys.stdin > > >>> 'idlelib' in str(sys.stdin) > True > > The module may not always been a part of the representation, so I will not guarantee that for anything previous. There is also > > >>> sys.stdin.__module__ > 'idlelib.rpc' > > and > > >>> 'idlelib' in sys.modules > True > > I like this best. It is False in the standard interpreter on startup and I am sure not stdlib module imports idlelib. So as long as your program does not (and there is no reason to) it should be safe. > > -- > Terry Jan Reedy > > _______________________________________________ > IDLE-dev mailing list > IDLE-dev at python.org > http://mail.python.org/mailman/listinfo/idle-dev From alh443 at gmail.com Tue Jan 22 06:26:53 2013 From: alh443 at gmail.com (pedro qwerty) Date: Tue, 22 Jan 2013 02:26:53 -0300 Subject: [Idle-dev] silly "bug" Message-ID: I'm using IDLE 2.7.3, python 2.7.3, and tk (don't know what it is) 8.5 The "bug" is that when you close the IDLE window, it asks you if you want to save your work, but if you click again, another new window appears, and if you click enought times you can get a lot of message boxes saying if you want to save your work, so, if you didn't know this, you may want to. Bye, Pedro. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bee10 at zips.uakron.edu Mon Jan 7 03:21:54 2013 From: bee10 at zips.uakron.edu (Brian Eckley) Date: Mon, 07 Jan 2013 02:21:54 -0000 Subject: [Idle-dev] Apple Message-ID: <67538422-5E1F-42F4-8FCE-94AC5FC11CE2@zips.uakron.edu> Hi, I'm having a problem with the preference tab in idle. If I try to open it, it closes and say's there was an error. Has anyone else had that problem? From tjreedy at udel.edu Fri Jan 18 13:56:01 2013 From: tjreedy at udel.edu (Terry Reedy) Date: Fri, 18 Jan 2013 07:56:01 -0500 Subject: [Idle-dev] Fwd: atexit handler in IDLE? In-Reply-To: <77873E06-908A-44F9-AB5F-D13F20703A73@spvi.com> References: <24E53D14-FD57-4FE2-8763-99149773650B@spvi.com> <50F6D29A.9010006@gmail.com> <50F79DBE.6050707@gmail.com> <57FED75E-88BD-49D2-B69E-A07584389BA3@spvi.com> <77873E06-908A-44F9-AB5F-D13F20703A73@spvi.com> Message-ID: <50F94661.5050601@udel.edu> On 1/18/2013 7:06 AM, Steve Spicklemire wrote: > I have to say... the deeper implications of one approach or another on IDLE as a whole are pretty much lost on me. ;-( The main point is that IDLE should run code pretty much the same way as the interpreter, taking into account that it has the extra feature of multiple interactive sessions, with or without a preceding batch run. In particular, it should not disable normal behavior, as it seems to do now. The subsidiary point is that we have to know the details of 'normal' to imitate those details. > It would be nice if this behavior could be incorporated into IDLE at some point, Once I, Roger, or any other interested developers agree on where and how, I think it should and will be. -- Terry Jan Reedy From ronaldoussoren at mac.com Wed Jan 23 21:02:16 2013 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Wed, 23 Jan 2013 21:02:16 +0100 Subject: [Idle-dev] Apple In-Reply-To: <67538422-5E1F-42F4-8FCE-94AC5FC11CE2@zips.uakron.edu> References: <67538422-5E1F-42F4-8FCE-94AC5FC11CE2@zips.uakron.edu> Message-ID: <021375C0-8393-4D0F-AA52-5B461B4AD357@mac.com> On 7 Jan, 2013, at 3:21, Brian Eckley wrote: > Hi, I'm having a problem with the preference tab in idle. If I try to open it, it closes and say's there was an error. Has anyone else had that problem? Could be a problem with Tk, see for more information. Ronald > _______________________________________________ > IDLE-dev mailing list > IDLE-dev at python.org > http://mail.python.org/mailman/listinfo/idle-dev From kw at codebykevin.com Thu Jan 24 02:24:17 2013 From: kw at codebykevin.com (Kevin Walzer) Date: Wed, 23 Jan 2013 20:24:17 -0500 Subject: [Idle-dev] Apple In-Reply-To: <021375C0-8393-4D0F-AA52-5B461B4AD357@mac.com> References: <67538422-5E1F-42F4-8FCE-94AC5FC11CE2@zips.uakron.edu> <021375C0-8393-4D0F-AA52-5B461B4AD357@mac.com> Message-ID: <51008D41.5050303@codebykevin.com> On 1/23/13 3:02 PM, Ronald Oussoren wrote: > > On 7 Jan, 2013, at 3:21, Brian Eckley wrote: > >> Hi, I'm having a problem with the preference tab in idle. If I try to open it, it closes and say's there was an error. Has anyone else had that problem? > > Could be a problem with Tk, see for more information. > > Ronald A patch for the issue is here: http://bugs.python.org/issue15853 Kevin -- Kevin Walzer Code by Kevin http://www.codebykevin.com