On Fri, Jun 21, 2013 at 9:15 AM, Andreas Kloeckner <[email protected]> wrote: > Aaron Meurer <[email protected]> writes: >> I wanted to ask here before I opened an issue in case this is already >> implemented. Is there a way to make PuDB hit breakpoints without >> putting a set_trace, or using the pudb entry point script? I want >> something like >> >> pudb.set_trace(stop=False) >> >> that I can put in the main() of my program, that will act just like >> set_trace() and an immediate 'c'. >> >> If such a thing doesn't exist, do you think that set_interrupt_handler >> should do this (and even if it does, do you think it should)? >> Sometimes it feels annoying that you have to get pudb sufficiently >> "primed" to make it stop at breakpoints. > > That sounds like a reasonable feature. I wouldn't be opposed.
I opened https://github.com/inducer/pudb/issues/76 for it. > >> Also, what are the disadvantages of running code "through" PuDB (i.e., >> set_trace and then 'c'), as opposed to independently of it? Is it >> sufficiently slower? > > If you've got breakpoints set (== bdb actually does tracing), it's pretty > slow. Without breakpoints, there shouldn't be a speed penalty. > > Side note: A worthy mission would be to replace bdb with something less > crappy. winpdb's rpdb2 has juicy claims over how much faster it is than > bdb, but unfortunately it's GPL'd. > > Andreas > I'm not a fan of GPL too, though for me it's just philosophical, not technical. But there may be people using PuDB who wouldn't be able to use it if it were GPL, or even LGPL. Regardless, I don't have time to work on PuDB right now. I may in the future, though. If I did have a chance to look at this particular issue, though, the first thing I would do is profile bdb vs rpdb2 to see exactly why there is a speed difference. By the way, will you be at SciPy? Aaron Meurer _______________________________________________ Pudb mailing list [email protected] http://lists.tiker.net/listinfo/pudb
