[IPython-user] ipython prevents sys.last_traceback (etc.) from being set?

Fernando Perez Fernando.Perez at colorado.edu
Fri Mar 10 12:34:30 CST 2006

Zachary Pincus wrote:
> So, from more reading of the python docs (though by no means  
> exhaustive), it seems that sys.last_traceback it thread-safe if it is  
> only set from interactive threads (of which there is at most one at a  
> time). The standard exception handler does this, I presume.
> So, is there any way in ipython to find out if the current thread is  
> the interactive one? Or is the handler only installed for interactive  
> threads?
> Anyhow, something along that route is probably the way to ensure  
> thread-safety for last_traceback.
> Zach
> On Mar 10, 2006, at 5:26 AM, Ville Vainio wrote:
>>On 3/10/06, Zachary Pincus <zpincus at stanford.edu> wrote:
>>>Correct me if I'm wrong, but there's nothing thread-unsafe about
>>>*setting* these values, is there? It's just unsafe to use them? Or is
>>>even setting them in a multithreaded context bad?
>>It's the user of these variables that chooses to take the risk, yes. I
>>think we should set them and let the programs choose whether to use
>>them or not.

Well, it's a little complicated: in multi-threaded mode, there are _two_ 
exception handlers which can both fire.  IPython's 'normal' one is typically 
activated by exceptions in user code, while code which is part of GUI 
libraries typically falls through and ends up caught by sys.excepthook.  In 
non-threaded ipython, sys.excepthook is the crash handler, but I had to 
deactivate it for the threaded modes, since it was reporting 'ipython crashed' 
for all sorts of non-crash conditions.

In summary, if someone can sort out the mess that is having multiple threads 
firing exceptions which follow different internal paths, I'd love to hear. 
Note that I tried a LOT to have the 'normal' handler catch gui exceptions, and 
always failed.  And to this day, I don't understand why, since perfectly 
innocent looking code like:


never caught, and sys.excepthook() ended up always called.

Part of the problem with threads is that you need to set _several_ variables 
(sys.last_{type,value,traceback}).   It is perfectly possible to get a 
thread-switch after you've set only some of these and not all.  At that point, 
I have no idea what a debugger like pdb would do.

So I'm fully open to revisiting this problem and finding the best possible 
compromise, but I know it's a bag of thorns.  If we can find a sensible 
solution (not necessarily perfect), we'll apply it.  But I don't want to do 
something that makes things worse, which is the frequent outcome of seemingly 
sensible changes when multithreaded code is in the picture.



More information about the IPython-user mailing list