Python Debugging With pdb: Summary
Here are all of the commands you covered in this course:
-
p
: Print the value of an expression. -
pp
: Pretty-print the value of an expression. -
n
: Continue execution until the next line in the current function is reached or it returns. -
s
: Execute the current line and stop at the first possible opportunity (either in a function that is called or in the current function). -
c
: Continue execution and only stop when a breakpoint is encountered. -
unt
: Continue execution until the line with a number greater than the current one is reached. With a line number argument, continue execution until a line with a number greater or equal to that is reached. -
l
: List source code for the current file. Without arguments, list 11 lines around the current line or continue the previous listing. -
ll
: List the whole source code for the current function or frame. -
b
: With no arguments, list all breaks. With a line number argument, set a breakpoint at this line in the current file. -
w
: Print a stack trace, with the most recent frame at the bottom. An arrow indicates the current frame, which determines the context of most commands. -
u
: Move the current frame count (default one) levels up in the stack trace (to an older frame). -
d
: Move the current frame count (default one) levels down in the stack trace (to a newer frame). -
h
: See a list of available commands. -
h <topic>
: Show help for a command or topic. -
h pdb
: Show the fullpdb
documentation. -
q
: Quit the debugger and exit.
Congratulations, you made it to the end of the course! What’s your #1 takeaway or favorite thing you learned? How are you going to put your newfound skills to use? Leave a comment in the discussion section and let us know.
00:00 We covered a lot of different commands in this course and you’ll find all of them down below the video for future reference.
00:08 In this course, we learned how to print expressions, step through code, use breakpoints, continue execution, display expressions, and see stack traces that show the path of execution up to a certain stack frame. This might seem like a lot to understand at first, especially when we have GUI-based debuggers at our disposal, but I’d encourage you to write some simple programs and try pdb for yourself.
00:39 The more you use it, the more sense it will make, and the more comfortable you’ll be with the tool.
00:46 You never know when it’ll come in handy. We also have a handy pdb Command Reference, which I recommend downloading and keeping open while you’re practicing your pdb skills.
00:59 This PDF shows you all the pdb commands you can execute, including ones not covered in this video course. It’s a great resource to have, especially when you’re just getting started with pdb.
01:12 I’ve linked that down below.
01:15 I am Austin Cepalia with realpython.com. Thanks for watching this and supporting us with your subscription. Happy coding!
Yvonne Wilmot on Sept. 25, 2020
Thanks that was great … Love the extra pdb++ .. until I came to the pdbpp decorator @pdb.hideframe and got an error. (I’m running on Windows with Python 3.8.5 in PyCharm)
import pdb
def log_in(username):
pdb.set_trace()
if username != "steve":
greet(username)
else:
print("steve is not welcome here")
@pdb.hideframe
def greet(name):
print(f"Hello {name}!")
user_input = input("Enter your name: ")
log_in(user_input)
I get the following error when trying to run my program in the command line:
(venv) C:\Users\YvonneW\python\my_debugging>python example6.py
Traceback (most recent call last):
File "example6.py", line 14, in <module>
def greet(name):
File "C:\Users\YvonneW\python\my_debugging\venv\lib\site-packages\pdb.py", line 1266,
in hideframe
c = types.CodeType(
TypeError: an integer is required (got type bytes)
Did I miss something?
Austin Cepalia RP Team on Sept. 25, 2020
@Yvonne Wilmot Hmm, that code looks right to me. Judging by the stacktrace, it looks that’s an issue with PDB++. I’ve seen this TypeError a lot with modules that are incompatible with Python 3.8. Try running the script with 3.7 and see if that works.
Ghani on Oct. 25, 2020
Very informative; thanks!
stephenm on Feb. 28, 2021
Excellent tutorial! Easy to follow, clearly explained. Thank you!
tobenary on May 17, 2021
I have my company code running on docker containers. will it work there as well? also, whats the best way of printing values? ( or, I guess that we need to use logger.info(f”and then, our {value}”)
Bartosz Zaczyński RP Team on May 18, 2021
@tobenary What you need in this case is running a remote debugger. The easiest way would be to use an IDE like PyCharm, which takes care of the details. However, if you wanted to use PDB in the command-line, then that’s also possible. Google the phrase “pdb docker remote debugging”.
Omar Rizwani on Aug. 1, 2022
pdb++
is a handy little extra…
Pavneet Ghai on Oct. 25, 2022
I often check the type of variable value, is there a way to check the type of variable? Most of the time I don’t have write mode on files, I would prefer using python3 -m pdb fileName.py. can someone share video line on this please.
jankesjanco on Jan. 8, 2024
Thank you for the tutorial, I’ve learned a lot from it :)
Become a Member to join the conversation.
robotslave on Feb. 3, 2020
Thanks for the course. Pdb is much like the Perl debugger. I have one problem though - can’t get it working with Robot. If I launch the Robot executable with Pdb, I can specify a breakpoint (at least it is not rejected) - but then pdb doesn’t seem to stop at it at all. If tends to stop where there is a Pause (Robot keyword) call in the code, and at that point all the scope that is available is the Pause keyword scope. So any variables I want to print are only from the Pause Robot keyword - completely useless. Do you have any suggestions how to make it work with Robot?