Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Debugging Python Like a Boss

zapier.com

Post reply on HN
Print view View original

71–80 of 100 posts

Re: Debugging Python Like a Boss

#71

Post by memracom »

Print debugging is faster. Most people who use this technique also don't make so many mistakes because they take the time to review their code, not to mention writing unit tests.

Their debug cycle is a) notice something is not quite right. b) insert some print statements in the code that they just changed. c) run it again. d) look at the code and the print statements to see where they made a wrong assumption, fix it and move on.

No need for figuring out where to set a break or single stepping through too much tangle.

Re: Debugging Python Like a Boss

#72

Post by bqe »

hcarvalhoalves wrote: post #3

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…

I've used pdb.set_trace() before when I had a series of complex breakpoints. I kept them in my git stash.

Perhaps I should add a pre-commit hook to grep for pdb.set_trace() and reject commits with that in them.

http://stackoverflow.com/a/10840525/2151949

Re: Debugging Python Like a Boss

#73

Post by memracom »

epenn wrote: post #49
epenn wrote: post #23

Earlier quoted context omitted.

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 ch…

Normally I wouldn't comment on someone downvoting me. However I'm going to presume there is a very high probability that it's due to my analogy with the goto statement, something which most programmers seem to view as inherently evil thanks either to received dogma or to a misunderstanding of the context of Dijkstra's original paper on the subject. The point of my post was that there is a time and place for everythin…

Exceptions are gotos. Just like singleton objects are global variables.

And knee jerk reactions can get you killed.

Re: Debugging Python Like a Boss

#74

Post by coolsunglasses »

haberman wrote: post #12

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…

There are better ways to do this style of debugging:

https://github.com/clojure/tools.trace

https://github.com/coventry/Troncle (I can use this from nRepl'ing into production servers)

Re: Debugging Python Like a Boss

#75

Post by keypusher »

coolsunglasses wrote: post #74
haberman wrote: post #12

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…

There are better ways to do this style of debugging: https://github.com/clojure/tools.trace https://github.com/coventry/Troncle (I can use this from nRepl'ing into production servers)

Does anything like that exist for python?

Re: Debugging Python Like a Boss

#76

Post by keypusher »

Does anyone know of good remote debugging tool or even a way to attach to a running local python process and get into the breaks? We have automated testing in python, and it is kicked off via a daemon, so executing the scripts by hand can be a pain.

Re: Debugging Python Like a Boss

#77

Post by coolsunglasses »

keypusher wrote: post #75
coolsunglasses wrote: post #74

Earlier quoted context omitted.

There are better ways to do this style of debugging: https://github.com/clojure/tools.trace https://github.com/coventry/Troncle (I can use this from nRepl'ing into production servers)

Does anything like that exist for python?

Decorators would be your best bet, but it won't be quite as nice.

Re: Debugging Python Like a Boss

#78

Post by est »

remote debugging with pdb+socket

1. first listen to a socket with nc -l -U 1.sock

2. Add this to your python script.

    import socket, pdb

    s = socket.socket(socket.AF_UNIX, socket.SOCK_STREAM)
    s.connect('1.sock')
    f = s.makefile()
    pdb.Pdb(stdin=f, stdout=f).set_trace()

    raise wtf
3. now debug in nc. enjoy.

Re: Debugging Python Like a Boss

#79

Post by chris_mahan »

keypusher wrote: post #76

Does anyone know of good remote debugging tool or even a way to attach to a running local python process and get into the breaks? We have automated testing in python, and it is kicked off via a daemon, so executing the scripts by hand can be a pain.

I run an xmlrpc server, then have the jobs log to the server while they are running. Then I just look at the server logs as they come in (they're files, so tail works fine)

This works across the internet.

Re: Debugging Python Like a Boss

#80

Post by tejaswiy »

edwinnathaniel wrote: post #6

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 was about to bring up the exact same thing. I see some positivies in the the text editor not IDE approach that linux / unix folks take, but I don't find this approach so amazing that programmers need to trade intellisense / auto complete / In-IDE debugging / Refactoring features for this.
Post reply on HN