Live data from Hacker News

Debugging Python Like a Boss

zapier.com

21–30 of 100 posts

Re: Debugging Python Like a Boss

#21

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…

I tend to find myself relying on debuggers for tracking down bugs in other people's code where I might not have a good grasp of the big picture, but relying more on print statements for debugging my own code.

Absolutely. Alternatively, debuggers are a godsend when there is a long deployment cycle.

Re: Debugging Python Like a Boss

#22
post #8

I've been using Python for a while for fun and Ruby (Rails) on and off. I've always find it interesting how the Python/Ruby community debug your code both during development (coding or writing unit-tests) and perhaps in production as well (for the record, I use "print" as my debugging tool). I'm a long time Eclipse user who has recently converted to IntelliJ (almost a year) and the debugger that comes with these edit…

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.

Re: Debugging Python Like a Boss

#23

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…

To expand on your point, I look at print statements in the same light as goto statements. There is a time and place for both, just make sure it's the best tool to accomplish your goal. In C I often use gotos for error handling, but I wouldn't use them in situations where higher-level branching constructs are more suitable. Similarly, sometimes you don't need the features of a heavy-weight debugger but just want to check some output. Print statements are great for this.

Re: Debugging Python Like a Boss

#24

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…

I agree. That, coupled with keeping your functions small (doing 1 thing) and tight, and being disciplined at writing unit tests can go a LONG way when it comes to debugging with simple print statements. Normally I'm able to hone in bugs with a few strategically placed prints, and a re-run of the unit tests. Pouring over stdout log is usually trivial with an incremental search, and the print statement prefixed with some known unique chars.

Re: Debugging Python Like a Boss

#25

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…

One neat trick that I really like for ptrintf debugging is using conditional breakpoints and putting the call to the printing function inside the breakpoint condition. This lets you add print statements without editing the original code and makes it very easy to toggle them on and off.

Re: Debugging Python Like a Boss

#26

I've been using Python for a while for fun and Ruby (Rails) on and off. I've always find it interesting how the Python/Ruby community debug your code both during development (coding or writing unit-tests) and perhaps in production as well (for the record, I use "print" as my debugging tool). I'm a long time Eclipse user who has recently converted to IntelliJ (almost a year) and the debugger that comes with these edit…

I've used "println debugging" more than I have used an IDE's debugger, and am more comfortable with the former. I think it revolves around a different way of using them, and is likely very heavily influenced by having spent a lot of time developing with a REPL handy.

When I did mostly Java coding, I would tend to use println debugging rather than dive into the IDE's debugger, as I tended to be able to zero in more easily on what was going on when I took a holistic "Let's print out each item's id and name ..." approach to start.

Now that I do most of my code in Python, I use the interactive debugger almost exclusively.

With an IDE, I can look at variables' contents. What do I do when I want to check the result of a method call, though? It is likely tool unfamiliarity, but it's never been clear how to check that as something to inspect. (If you know how to do this, then you're a much more savvy user of the IDE's debugging tools than I am.) If I don't have the right breakpoint, or the right questions, I often glean little.

Println debugging is an easy way to see that you're looping incorrectly, or that All Your Data is bad in a way you didn't expect.

With a REPL-style debugger, I can treat it as an interactive question/answer session that lets me check things like contents of the database, or the values that helper methods return:

  > print len(foo.items)
  0
  # why??? Maybe the objects don't exist?
  > print Foo.objects.filter(bar=42)
  [foo1, foo2, foo3]
  # Let me place a new breakpoint then in 
  # my JsFoo.from_db_item() method, and try again ....
I think the nicest thing about an interactive debugger is that it lets me construct arbitrary expressions -- print lists of things, look at nested data, etc -- in the language I am already developing in. I always had a hard time doing something quite as powerful in Eclipse.

Re: Debugging Python Like a Boss

#27
post #26

I've been using Python for a while for fun and Ruby (Rails) on and off. I've always find it interesting how the Python/Ruby community debug your code both during development (coding or writing unit-tests) and perhaps in production as well (for the record, I use "print" as my debugging tool). I'm a long time Eclipse user who has recently converted to IntelliJ (almost a year) and the debugger that comes with these edit…

I've used "println debugging" more than I have used an IDE's debugger, and am more comfortable with the former. I think it revolves around a different way of using them, and is likely very heavily influenced by having spent a lot of time developing with a REPL handy. When I did mostly Java coding, I would tend to use println debugging rather than dive into the IDE's debugger, as I tended to be able to zero in more ea…

I used to do "println" debugging trick during my early days of programming until more senior people around me slap my hand and told me to use the debugger efficiently and effectively.

In Eclipse/IntelliJ you can set "Conditional Breakpoint" (only stop/break when certain conditions is met) very handy when debugging a loop. In addition to that, you can also set "breakpoint on any Exception".

Also, in Eclipse/IntelliJ, when the debugger hits the breakpoint, you could execute Java code within the context of that breakpoint (of course, java.lang is given by default in addition to the context of that breakpoint).

I've never done more complex debugging than that but I'm guessing you can write almost anything you want within the "evaluate window" in those IDEs.

Re: Debugging Python Like a Boss

#28

A good list of libraries, but please, don't use this in the middle of your code to set a break point: import pdb; pdb.set_trace(); There's a chance you forget this, check-in, and it ends in production. Use pdb facilities instead: $ python -m pdb Then set a breakpoint and continue: (Pdb) break : (Pdb) c This is trivial to automate from any editor or command line, so you don't even have to guess the path to the file. E…

How would I do that with something like django?

    $ python -m pdb manage.py runserver
    (Pdb) break mymodule/myfile.py:42
    (Pdb) c

Re: Debugging Python Like a Boss

#29

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.

Re: Debugging Python Like a Boss

#30
A very nice list of debuggers, but I'm wondering why there is no mentioning of the (very good) debugging support you can find in IntelliJ and Eclipse and mostly, why there is no mentioning of Winpdb [1]; a very nice and platform-independent Python debugger with a full-fledged GUI.

[1]: http://winpdb.org/

Post reply on HN