[hcarvalhoalves]

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

Then set a breakpoint and continue:

    (Pdb) break <filename.py>:<line>
    (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.

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

[lewaldman]

Here is my setup:

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

sys.excepthook = info

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

[cjg_]

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.

[codygman]

Yeah, I always catch my ipdb.set_trace() lines in testing.

[gknoy]

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.

[hcarvalhoalves]

Sure, that's beautiful in theory. But you have to remember to catch the strings "import pdb", "import ipdb", "import pydbgr", and the variations "from pdb import Pdb", "__import__('pdb')", all the permutations, and so on. Anyway, that's besides point.

Having to change the source to fire the debugger is a dumb way of debugging after all, and doesn't allow certain things (e.g., step thru a 3rd party library). Better coach the developers on how to use the tools properly.

[codygman]

I agree that this method is much better, and for some reason reminds me of the tooling vs programming languages discussion I was in the other day.

I guess it's because that is an example of ad-hoc (which typically misses a lot of edge conditions) tooling created to make up for language (or in this case tooling) inadequacies.

[jaytaylor]

This is great advice, I didn't know there was a better way than the scary import/set_trace() method. Thanks for sharing!

[bqe]

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

[hcarvalhoalves]

Since I claimed it was trivial to automate that from an editor, here's a plugin for setting up breakpoints on ST2:

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

[wodow]

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

[hcarvalhoalves]

(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/manage.py:11
    (Pdb) break
    Num Type         Disp Enb   Where
    1   breakpoint   keep yes   at /Users/hcarvalhoalves/Projetos/myproj/manage.py:11
	stop only if os.environ["DJANGO_SETTINGS_MODULE"] == "myproj.settings"

Really, it does a bunch of things. I wonder why developers are unaware of it.

http://docs.python.org/2/library/pdb.html

[wodow]

(a) I'm not too sure about, but (b) I didn't realise - thanks for that.

[hcarvalhoalves]

About (a)... there:

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

[codygman]

How would I do that with something like django?

[Newky]

You are right that this is not straight forward in Django.

There are a number of different routes in Django development that you may need to debug:

1. Debugging view endpoints when not using runserver (for example when testing out your actual deploy webserver). For this, none the debuggers will work, as you have no console to run through. I combat this by using winpdb that allows remote debugging.

2. Debugging either unittest based code or when using runserver, you can use the method described by hcarvalhoalves comment.

However, I still think that in lots of cases its more powerful to import in the code. With the necessary coverage in tests, it should always be picked up.

[codygman]

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

The above should work for tests if I understand correctly, though I haven't checked yet. This solves most of my current debugging problems, and if I'm reading correctly that would solve yours too?

I wonder if you could also use it with runfcgi or any of the other manage commands? I personally use nginx+gunicorn, but for testing production I could switch it to runfcgi or similar really quick.

To be honest though, I don't find myself ever debugging production.

[hcarvalhoalves]

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

[codygman]

Well that should have been obvious, thanks!

[brian_cooksey]

Thanks for the tip!