5 ms·

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 fo

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 https://gist.github.com/hcarvalhoalves/7587621

jaytaylor 13y ago
This is great advice, I didn't know there was a better way than the scary import/set_trace() method. Thanks for sharing!
brian_cooksey 13y ago
Thanks for the tip!
cjg_ 13y ago
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 13y ago
  Yeah, I always catch my ipdb.set_trace() lines in testing.
codygman 13y ago
How would I do that with something like django?
- hcarvalhoalves 13y ago
  $ python -m pdb manage.py runserver (Pdb) break mymodule/myfile.py:42 (Pdb) c
  - codygman 13y ago
    Well that should have been obvious, thanks!
- Newky 13y ago
  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 13y ago
    $ 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.
gknoy 13y ago
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 13y ago
  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 13y ago
    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.
wodow 13y ago
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 13y ago
  (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 http://docs.python.org/2/library/pdb.html
  - wodow 13y ago
    (a) I'm not too sure about, but (b) I didn't realise - thanks for that.
    - hcarvalhoalves 13y ago
      About (a)... there: https://github.com/hcarvalhoalves/sublime-pdburger https://github.com/hcarvalhoalves/sublime-pdburger
lewaldman 13y ago
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
bqe 13y ago
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 http://stackoverflow.com/a/10840525/2151949
hcarvalhoalves 13y ago
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 https://github.com/hcarvalhoalves/sublime-pdburger

jaytaylor 13y ago

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

brian_cooksey 13y ago

Thanks for the tip!

cjg_ 13y ago

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 13y ago
Yeah, I always catch my ipdb.set_trace() lines in testing.

codygman 13y ago

How would I do that with something like django?

hcarvalhoalves 13y ago
$ python -m pdb manage.py runserver (Pdb) break mymodule/myfile.py:42 (Pdb) c
- codygman 13y ago
  Well that should have been obvious, thanks!
Newky 13y ago
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 13y ago
  $ 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.

gknoy 13y ago

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 13y ago
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 13y ago
  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.

wodow 13y ago

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 13y ago
(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 http://docs.python.org/2/library/pdb.html
- wodow 13y ago
  (a) I'm not too sure about, but (b) I didn't realise - thanks for that.
  - hcarvalhoalves 13y ago
    About (a)... there: https://github.com/hcarvalhoalves/sublime-pdburger https://github.com/hcarvalhoalves/sublime-pdburger

lewaldman 13y ago

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

bqe 13y ago

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 http://stackoverflow.com/a/10840525/2151949

hcarvalhoalves 13y ago

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 https://github.com/hcarvalhoalves/sublime-pdburger