le dahut wrote: > > > Tim Golden wrote : >> le dahut wrote: >>> What strange is is that: >>> >>> try: >>> wsec.LookupAccountName(...) >>> except: >>> print 'Error' >>> >>> shows : >>> - a traceback, as if I didn't put LookupAccountName in a try/except >>> statement >>> - the string 'error' so the program has also switched to except as if >>> the try/except has been correctly interpreted >>> >>> So we can say that I get the two behaviours in one. At the exception >>> that the traceback is not complete, it only talks about the line >>> containing LookupAccountName, not entire traceback (the caller >>> function and its parents). >> >> Well that is an extremely clear description of the problem. And, >> unsurprisingly, I can't get it to fail at the interpreter or >> (just in case) from within a file. >> >> <guesswork> >> Is there any possibility that there's an atexit handler or a thread >> going on which is generating the other traceback? Or even a stray >> __del__ or something equally bizarre? Or maybe the code's dropping >> through after handling the exception to some other code which is >> printing the traceback? >> </guesswork> >> > > Actually, the code doesn't break, it continues its execution as if > try/except as done its work. > > It is run in a twisted reactor. > > "a stray _del_" could you be more precise ?
Have a look at: http://docs.python.org/ref/customization.html It's not easy to predict what's available when a __del__ is invoked. Indeed, it's not even guaranteed that it's called at all. In particular it may be called when other objects have been destroyed which it's attempting to use. That said, I doubt if that's the issue here since I would only expect __del__-related problems when the interpreter's actually exiting, not when the program carries on which is your case. TJG _______________________________________________ python-win32 mailing list python-win32@python.org http://mail.python.org/mailman/listinfo/python-win32
