81–90 of 100 posts
In all honesty I rarely feel the need for anything more. Generally I don't even need the print() because I stick to small self contained functions.
The exception is when I'm using a poorly documented or new to me open source library. I guess at times like that a debugger may be useful. So next time I run into such a situation I'll try out a debugger.
But I can't see much of a reason for it in my own code.
Earlier quoted context omitted.
You are doing it wrong, and you are making generalizations about these languages on the basis of your doing it wrong?
Yeah, it would help if you would point out what exactly this person is doing wrong.
Debuggers are cool and often necessary, but I disagree with this often-expressed sentiment that print-debugging is a primitive hack for people who don't know any better. Debugging is determining the point at which the program's expected behavior diverges from its actual behavior. You often don't know where where/when this is happening. Print-debugging can give you a transcript of the program's execution, which you ca…
Surprised no mention of JetBrains PyCharm. It's incredibly easy to use for debugging, even supports debugging gevent based code. I agree though, outputting print statements at different levels of severity, i.e. warning, error, info, etc. is a great way to see if things are working on a high level. For more granularity, debuggers are invaluable to figure out why a specific portion of code isn't working as expected.
All of the JetBrains products are super smart and efficient, and the community editions are no exception.
Earlier quoted context omitted.
Um most debuggers allow you set variables and execute a loop n times
And what if your bug is after the nth iteration of the loop, where the exact value of n is unknown (it's a bug, after all)? How many times are you going to set the variable and run the loop n times? Whereas with print-debugging and a grep you can filter for only unexpected/unusual output, and so narrow down to the likely cause, faster. Generalizing, of course. There are definitely cases where a debugger can be more e…
(gdb)> break
Breakpoint 1 at ....
(gdb)> cond 1 x cont
Although, to be honest, I mostly use a debugger as an exploratory printf these days:
(gdb)> call pretty_print(my_data)
I also need to look into backwards stepping. GDB can trace executions of the program, and when you see the issue pop up, you can step backwards in time to see what caused it.
The most frustrating thing (experienced in both Javascript and Python) is the "oh uncaught exception? let me just quit everything" model. Most of the time, if I were just given an interactive prompt right then, I could spend 1 minute looking at local variables, maybe get a special stack trace variable to look at that, then be over with it. Instead I have to stick in some print statements and start everything over aga…
There's a nice trick to enable this behavior for standard Python code run at the command line. Write the body of your code inside a main() function, then call it using the following toplevel block: if __name__ == "__main__": try: main() except KeyboardInterrupt: # allow ctrl-C raise except Exception as e: import sys, traceback, pdb print e type, value, tb = sys.exc_info() traceback.print_exc() pdb.post_mortem(tb) Thi…
Earlier quoted context omitted.
There's a nice trick to enable this behavior for standard Python code run at the command line. Write the body of your code inside a main() function, then call it using the following toplevel block: if __name__ == "__main__": try: main() except KeyboardInterrupt: # allow ctrl-C raise except Exception as e: import sys, traceback, pdb print e type, value, tb = sys.exc_info() traceback.print_exc() pdb.post_mortem(tb) Thi…
Minor gripe, the except KeyboardInterrupt isn't necessary, since KeyboardInterrupt is a BaseException, not an Exception.
I thought there would actually be some innovative techniques in this article.
Perhaps a better title would be, "A review of python debuggers".
Not just remote debugging of a halted program - you can actually inspect and alter variables and issue commands into the executing code.
Is there a way to do that in, say, Python?
Earlier quoted context omitted.
This is only convenient in cases where (a) the breakpoint line doesn't move around a lot between different executions, as you edit the code; (b) you don't want to programatically invoke the debugger (i.e. if f(x): pdb.set_trace() )
(a) This can be solved with an editor. Alternatively, you can use a function name instead of `filename:linenumber` to set a breakpoint. (b) Pdb supports conditions with `filename:lineno, statement`. Statement will have access to local scope. E.g.: $ python -m manage.py runserver (Pdb) break manage.py:11, os.environ["DJANGO_SETTINGS_MODULE"] == "myproj.settings" Breakpoint 1 at /Users/hcarvalhoalves/Projetos/myproj/ma…
Earlier quoted context omitted.
(a) This can be solved with an editor. Alternatively, you can use a function name instead of `filename:linenumber` to set a breakpoint. (b) Pdb supports conditions with `filename:lineno, statement`. Statement will have access to local scope. E.g.: $ python -m manage.py runserver (Pdb) break manage.py:11, os.environ["DJANGO_SETTINGS_MODULE"] == "myproj.settings" Breakpoint 1 at /Users/hcarvalhoalves/Projetos/myproj/ma…
(a) I'm not too sure about, but (b) I didn't realise - thanks for that.