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

11–20 of 100 posts

Re: Debugging Python Like a Boss

#11

Post by siliconc0w »

What is also useful are the various web framework's support for debugging in realtime. If you haven't worked on a web application that lets you just type code in when it throws a 500 I highly recommend it.

Also what I like to do with ipdb is set a debug point and just write new functionality in real time. Most good programmers probably do this in their heads but having a computer do it for you is the next best thing. You catch bugs almost immediately (hey this variable isn't supposed to be empty!). It feels pretty cool to send a request to a web app and just pound out the code to make it respond correctly before the browser gives up on the HTTP connection.

Re: Debugging Python Like a Boss

#12

Post by haberman »

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 can look at to hone in on the moment where things go wrong. Stepping through a program's execution line-by-line and checking your assumptions can be a lot slower in some cases. And most debuggers can't go backwards, so if you miss the critical moment you have to start all over again.

These are two tools in the toolbox; using print debugging does not mean you are not "a boss."

Re: Debugging Python Like a Boss

#14

Post by pjmlp »

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…

> So sometimes I'm wondering how productive Python/Ruby + VIM/Emacs users. Just an honest question really.

As much as a UNIX System V user.

Re: Debugging Python Like a Boss

#15

Post by cjg_ »

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…

If miss a line like that which is very easy to spot in a diff, which other things end up in your production environement?

And obviously any test covering that line will fail/hang.

Re: Debugging Python Like a Boss

#16

Post by brian_cooksey »

defrex wrote: post #13

This article is missing pdb++[1], which I would argue is much less buggy then ipdb while having essentially all the same features. [1] https://pypi.python.org/pypi/pdbpp/

Thanks for the link. It wasn't one that came up when I was searching, but it definitely looks like another solid option. Sticky mode in particular sounds slick.

Re: Debugging Python Like a Boss

#17

Post by Symmetry »

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…

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.

Re: Debugging Python Like a Boss

#18

Post by codygman »

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…

How would I do that with something like django?

Re: Debugging Python Like a Boss

#19

Post by gknoy »

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…

We avoid that by having a build step fail if 'import pdb' exists in our codebase. You could do similar for any of these tools. This will then lead to build failures in one's automated build system, and flag pull requests as not-yet-ready to be merged with our master branch.

If one doesn't have an automated test process, then I suspect one has bigger potential errors that could sneak in than an errant pdb breakpoint. I'll just assume that your release / merge process DOES include a test suite that you can add this sort of test to.

Re: Debugging Python Like a Boss

#20

Post by codygman »

cjg_ wrote: post #15
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…

If miss a line like that which is very easy to spot in a diff, which other things end up in your production environement? And obviously any test covering that line will fail/hang.

Yeah, I always catch my ipdb.set_trace() lines in testing.
Post reply on HN