31

I used ipdb.set_trace() somewhere in my Python code. Is it possible to ignore this break point using a IPDB command?

clear tells me that it cleared all break points, but IPDB stops again when it stumbles upon the line with ipdb.set_trace().

disable 1 tells me: No breakpoint numbered 1 ignore 1 says: Breakpoint index '1' is not valid

To clarify: Of course I could simply remove the break point from my source code. But this would require to quit the debugger and to start it again. Often it needs a lot of work to get somewhere and restarting the debugger makes life more difficult. Also if there is a huge loop and you want inspect objects in the loop, the easiest is to place a break point in the loop directly after the object. How could I then skip the loop (and all thousands of calls set_trace()) and step through the code after the loop using next?

lumbric
  • 7,644
  • 7
  • 42
  • 53
  • 1
    breakpoints are only for debugging, It is a good idea to keep track of _where_ you have set it. You are better off doing a `grep` or a search to figure out where it is. – karthikr Sep 30 '13 at 16:17
  • 1
    @karthikr Yes, of course. I think you misunderstood my question a bit. I tried to clarify how I'd like to use the debugger. – lumbric Sep 30 '13 at 21:48

4 Answers4

49

Well, you CAN take advantage of the fact that anything in Python is an object. While in the debugger, you can do something like this:

def f(): pass
ipdb.set_trace = f

set_trace will still be called, but it won't do anything. Of course, it's somewhat permanent, but you can just do

reload ipdb

and you'll get the original behaviour back.

(why would you do this? when you accidentally put a breakpoint in an often-called function that is usually called under a try/except. Once you realize you're stopping 1000 times in this function, you try to ctrl-c, but that gets caught by the try/except and you're back in ipdb again. So, if you're in low-level code, make sure your set_traces have some context:

if myvar in ['some', 'sentinel', 'values']:
    ipdb.set_trace()

etc.

Corley Brigman
  • 11,633
  • 5
  • 33
  • 40
  • 1
    +1 for the great suggestion of simply overwriting `set_trace()`. Anyhow, this does not enable to delete a specific break point. – lumbric Sep 30 '13 at 21:49
  • 2
    it should be possible to extend this concept to eliminate just a single breakpoint, by using the inspect module to determine the current file/line, and either return (doing nothing) or call the original ipdb.set_trace(). i don't have a recipe but i have had use of this a couple times so this is inspiring me to put one together... – Corley Brigman Sep 30 '13 at 23:43
  • 4
    This happens to me quite a bit when working with test suites. If you're stuck and just want your shell prompt back, a simple `del ipdb.set_trace` works like a charm. – Ben Davis Jun 12 '14 at 16:40
27

After learning from Corley

ipdb.set_trace = lambda: None

Works for me.

GLaDOS
  • 620
  • 6
  • 17
4

Based on Corley and GLaDOS answers, you can use this trick to set_trace for several loops without overwriting the ipdb.set_trace()

import ipdb
dbg1 = ipdb.set_trace  # BREAKPOINT
for i in range(10):
    my_var2 = 10 / 3
    dbg1()  # BREAKPOINT
    dbg1 = lambda: None
    print(my_var2)


dbg2 = ipdb.set_trace  # BREAKPOINT
for i in range(10):
    my_var2 = 20 / 3
    dbg2()  # BREAKPOINT
    dbg2 = lambda: None
    print(my_var2)

Works for me like a charm.

Alz
  • 71
  • 1
  • 4
-4

Running the program should also tell you exactly where you've set your idb.set_trace() when it's being hit (otherwise, try the where or bt commands). You can then remove that line from the file, and restart the program.

Otherwise, you might find this useful, if you feel more experimental.

Community
  • 1
  • 1
m01
  • 9,033
  • 6
  • 32
  • 58