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

41–50 of 100 posts

Re: Debugging Python Like a Boss

#41

Post by brian_cooksey »

ruxkor wrote: post #30

A very nice list of debuggers, but I'm wondering why there is no mentioning of the (very good) debugging support you can find in IntelliJ and Eclipse and mostly, why there is no mentioning of Winpdb [1]; a very nice and platform-independent Python debugger with a full-fledged GUI. [1]: http://winpdb.org/

Mostly because I'm a VIM + command line type of guy :)

I'm aware there are a slew of plugins/built-ins with IDE's that I didn't cover. As I mentioned in a comment on the post, I think a disclaimer that stated my preference would have helped.

Re: Debugging Python Like a Boss

#42

Post by rtpg »

The most frustrating thing (experienced in both Javascript and Python) is the "oh uncaught exception? let me just quit everything" model. Most of the time, if I were just given an interactive prompt right then, I could spend 1 minute looking at local variables, maybe get a special stack trace variable to look at that, then be over with it.

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

Re: Debugging Python Like a Boss

#43

Post by masklinn »

ufo wrote: post #25
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…

One neat trick that I really like for ptrintf debugging is using conditional breakpoints and putting the call to the printing function inside the breakpoint condition. This lets you add print statements without editing the original code and makes it very easy to toggle them on and off.

Some IDEs have support for doing that without the hack. Xcode for instance, when you set a breakpoint you can edit it to not break, and execute custom actions (logging stuff, executing debugger commands, executing a shell script, executing actionscript, playing a sound).

A condition, if set, will then apply to whether the action should or should not be applied.

The great part is they can all be combined, so you can setup a breakpoint which will pre-log the info you know you'll need then drop you in the visual debugger with all base information waiting for you.

Re: Debugging Python Like a Boss

#44

Post by masklinn »

hcarvalhoalves wrote: post #36
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 only use "print debugging" (using the logging facilities more often than not) if it's something I can leave in the codebase, like logging a function call and it's parameters, or when a routine is being skipped; then a debugger if I want to check the interface or docstring of some object or retry a call with different parameters on the REPL.

Alternatively, if your language/runtime/whatever supports it you can use dtrace for printf-debugging without editing the source.

Re: Debugging Python Like a Boss

#45

Post by wodow »

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…

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

Re: Debugging Python Like a Boss

#46

Post by hcarvalhoalves »

wodow wrote: post #45
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…

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

(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

Re: Debugging Python Like a Boss

#47

Post by Newky »

codygman wrote: post #18
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?

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.

Re: Debugging Python Like a Boss

#48

Post by Widdershin »

rtpg wrote: post #42

The most frustrating thing (experienced in both Javascript and Python) is the "oh uncaught exception? let me just quit everything" model. Most of the time, if I were just given an interactive prompt right then, I could spend 1 minute looking at local variables, maybe get a special stack trace variable to look at that, then be over with it. Instead I have to stick in some print statements and start everything over aga…

Flask makes this really nice. When in Debug mode, if an exception happens, you get an interactive stack trace, and you can easily jump into console in each level.

Re: Debugging Python Like a Boss

#49

Post by epenn »

epenn wrote: post #23
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…

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 everything -- print statements in the context of this thread -- and I used gotos as an additional analogy/example. So in case anyone sees this and wonders why I would actually consciously choose to use a goto statement, please see the following goto entry in CERT's Secure Coding Standard [1] for a concise but thorough explanation.

https://www.securecoding.cert.org/confluence/display/seccode...

Re: Debugging Python Like a Boss

#50

Post by lewaldman »

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…

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

Post reply on HN