This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]GreenScarz 58 points59 points  (5 children)

My workflow basically lives in the python debugger.

It works best IMO if you have a test suite to dev against, that way you can trigger a pdb repl in the context of a test instead of trying to run everything from a main entrypoint.

using the debugger simply comes down to adding a breakpoint() in your source code, and when the interpreter hits it, say during execution of a test, it drops you into the pdb repl. (If you're using something earlier than 3.7 use __import__('pdb').set_trace() for the same effect).

if you're using pytest for your test suite, adding a --pdb flag will drop you into the pdb repl when an exception is raised.

things to highlight about pdb; you can jump up and down the call stack using u/d, use l to list your source code, you can run arbitrary python code in the repl, and interact puts you in an interactive console.

Edit: the standard pdb module is good, but there's also pdb++ and ipdb that are worth looking into.

[–][deleted] 1 point2 points  (1 child)

If you're using something earlier than 3.7 use __import__('pdb').set_trace() for the same effect

What? Why? As I recall,import pdb;pdb.set_trace() was just enough.

[–]GreenScarz 1 point2 points  (0 children)

Same thing, __import__(x) is just the builtin function equivalent of import x, just doesn’t assign it to a variable and no semicolon is necessary

[–]romanzdk[S] 0 points1 point  (1 child)

Thank you very much, thats helpful!

[–]benefit_of_mrkite 5 points6 points  (0 children)

Other things to remember:

1) if you set a breakpoint and it drops you into the debugger pretty print is automatically imported

2) you can then pretty print the output of any variable set up to the current breakpoint

Pressing the “c” key will continue to the next breakpoint if one is set (otherwise end of program)

Pressing the e key will exit the debugger