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."

    import pdb; pdb.set_trace();

    $ python -m pdb <myscript>

    (Pdb) break <filename.py>:<line>
    (Pdb) c

EDIT: For the lazy, here's a script to set breakpoints from the command line and run your scripts:

https://gist.github.com/hcarvalhoalves/7587621

Instead I have to stick in some print statements and start everything over again.

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 editors is something I can't live without hence I have not moved to Emacs or VI(m) or whatever the UNIX hackers use because it would crippled my productivity significantly (or so I thought, feel free to criticize my point of view).

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

PS: most Java IDE debuggers can do local AND remote AND has some support for hotswap code.

It's an early stage project, but hopefully demonstrates that there is a middle ground between "Everything in an 80x25 text window" and "500lb IDE gorilla".

(Full disclosure: I'm the core developer of Bugjar)

http://www.youtube.com/watch?v=wvJaKQ94lBY

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.

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?

[1] https://pypi.python.org/pypi/pdbpp/

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.

I thought there would actually be some innovative techniques in this article.

Perhaps a better title would be, "A review of python debuggers".

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.

Once the weird behavior is covered, usually print debugging is even better than pdb because it will encourage you to extend the test suite.

What I would like though is a special monkey patching in python that allow my to write print like "p this that" and will prettyprint this and that on stdout

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

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

https://news.ycombinator.com/item?id=6770412

But I'm happy. When I posted, it failed to generate a discussion. If it were identified as a dupe this time, it would probably be forgotten.

It's a great article.

https://bitbucket.org/rpathsync/epdb

Looks really good.

"There are debugger people, and then there are printf people, you see..."

- I have a ~/.python/sitecustomize.py file with the following:

# Start debug on Exception

import bdb import sys

def info(type, value, tb):

   if hasattr(sys, 'ps1') \
         or not sys.stdin.isatty() \
         or not sys.stdout.isatty() \
         or not sys.stderr.isatty() \
         or issubclass(type, bdb.BdbQuit) \
         or issubclass(type, SyntaxError):
      # we are in interactive mode or we don't have a tty-like
      # device, so we call the default hook
      sys.__excepthook__(type, value, tb)
   else:
      import traceback, ipdb
      # we are NOT in interactive mode, print the exception...
      traceback.print_exception(type, value, tb)
      print
      # ...then start the debugger in post-mortem mode.
      ipdb.pm()

It will start ipdb automatically in case of any exception on command line called scripts.

- I use the awesome pdb emacs package for debug interactivelly during bigger bug hunts (Also for dev too... It's very a nice tool)

- Buutt... I still find the "print dance" to be my first-to-use quick tool.

edit: Fixed pasted code

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

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.

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

https://github.com/hcarvalhoalves/sublime-pdburger

(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() )

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 ....

As much as a UNIX System V user.