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

[Zachary Pincus]

Fernando,

Thanks for your reply.

> Well, it's not that ipython tries to block anything, it's that  
> these objects
> need to be _manually_ set.

Aah, I see. That makes sense.

>   It just so happens that python's default exception
> handler sets them, as ipython used to in the past.  But as of this  
> recent
> changeset:
>
> http://projects.scipy.org/ipython/ipython/changeset/975#file2
>
> I removed them.  The reason is thread-safety: the python docs  
> explicitly
> discourage their use in a threaded context (see http:// 
> www.python.org/doc/lib/module-traceback.html), and ipython has  
> multithreaded support.

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?

> But I'm afraid that I won't revert the patch, since I don't want to  
> risk introducing bugs for users of the multithreaded features  
> (which are out there).

The problem is that this patch, by changing the behavior of sys  
module from what is the documented standard, this introduces bugs for  
users of other features. Specifically, this breaks things for users  
of pdb, who are also out there.

Now, there's a conundrum if it's thread-unsafe to even set the  
last_traceback value. In that case, you will have to either  
definitely introduce bugs for pdb users, or risk bugs for  
multithreaded users. You'll have to decide which class of users is  
bigger or more important.

But if it's safe to set the value, and just not safe to use it, it  
seems like the thing to do is explicitly warn people not to use the  
values in threaded contexts, and just hope that they don't do  
anything stupid like ignore the warnings. Hobbling the single- 
threaded case just to keep multi-threaded users from not following  
the directions doesn't seem like the best solution.

However, in either case, this should probably be a configuration  
option and well-documented, since it breaks the standard python  
behavior and breaks a standard python module.

Now, you may disagree with my analysis above. I'll respect this.  
Thus, let me make a suggestion.
Given: pdb.pm() isn't as good as the enhanced pdb provided by ipython  
anyway
Given: multithreaded users can't use pdb.pm()
Given: currently, even single-threaded users can't use pdb.pm()

I therefore suggest that (regardless of what is done about  
sys.last_traceback) the magic %pdb command be extended to have a '.pm 
()' option that will dump the user into the enhanced pdb shell for  
whatever the latest traceback is. On python2.5, this will be easy  
because you can use the exc_info to get the traceback in a thread- 
safe manner.

Any thoughts?

Zach

> I hope this helps some.
>
> Cheers,
>
> f