[IPython-user] ipython prevents sys.last_traceback (etc.) from being set?
zpincus at stanford.edu
Fri Mar 10 00:30:17 CST 2006
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
> I removed them. The reason is thread-safety: the python docs
> 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
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-
> I hope this helps some.
More information about the IPython-user