Effective PyCharm Transcripts
Chapter: Debugging Python applications
Lecture: The debugging UI
Login or
purchase this course
to watch this video and the rest of the course contents.
0:00
Let's do a high level flyover through the debugging tools real quickly before we actually start
0:06
using them. So to start the debugger is very similar to running a program except for you click the bug instead of the play so you just create a run
0:14
configuration. However you might go about doing that. We've seen a bunch of ways and then you can debug it by just pressing this
0:21
debug thing. This works on regular programs but also works on web apps like with Flask run and it even works on Unit Tests.
0:29
So super good way to get started here. Once the debugger starts, you'll have this whole section here down in the bottom
0:36
especially if you hit a breakpoint. All the controls will light up right here. You can say where am I in my program?
0:43
So maybe you've hit a breakpoint or your paused or something like that or even running and it might be stuck somewhere,
0:49
you might have navigated all over different parts of your app or just forgotten where you are. You can click that button,
0:54
it will show you exactly where execution is paused, this one will allow us to step over debugging.
1:02
Think of step over is basically going line by line through a function or through execution There might be functions that are being called or classes,
1:10
methods you're being called and so on. That themselves are running a bunch of steps but you're not interested in those.
1:16
You just want to go one line by one line, by the next line through the current function you're in maybe following along with a return
1:24
value but not going in any deeper than where you are. If you do want to see what happens in those steps,
1:30
like for example, or in this wizard game here that we've seen previously, we have in a section where we call attack.
1:37
What happens inside of attack? Well, the wizard is getting some sort of role and determine its role.
1:44
But then also the creature is attacking is doing a defensive thing. If you want to dive down and see what's happening there you want.
1:50
'Step into' here now, there's a drawback maybe a over specificity of 'step into' 'step into' will step into everything. So for example,
2:00
if I'm trying to go through my code and my code happens to be calling requests to download some data and I press Step Into we're going inside requests.
2:09
We're gonna be diving into the details of requests or even the standard library in some instances. So often 'step into' is too much.
2:18
You really want to just look at your code, go through your details, but not the entire run times details. That might be too much in,
2:26
like I said, almost always is. So a better button to press is this step into my code.
2:32
So this if you were going through that diving into the details flow of your code
2:37
and your code calls requests. Step into 'my code' would go to the next bit of your code, not actually into what request is doing.
2:45
We can also do a step into 'forced' like going into a function call, going into a level of detail, You might be halfway through that and decide.
2:55
You know what this is not the problem. I'm going to go back up and carry on from where we get the return value
3:01
of this function you want 'step out' for that. Sometimes you just want to put your cursor on the line you're interested in and saying
3:08
I don't really know how we get here, but just run to this place. So put your cursor somewhere and press run to cursor or you can even right click
3:15
and say run to cursor finally. You might want to figure out what some comparison is or look at some details about your code. You can press this button,
3:26
it opens a calculator type thing where you type arbitrary Python expressions and it'll show you
3:30
the values like is this string equal to that string or is this string a sub string of that thing? Or does that set contain this item,
3:37
All those kinds of stuff you can quickly answer and throw away there if you want to ask those questions and remember it,
3:43
you could put it down into the variable section below two more things. Sometimes you'll hit a breakpoint and you want to resume like okay,
3:52
I've looked at the variables here, I want to keep going. Let it keep going and it's super likely you would
3:57
want to press the first green button to just keep going. You might press this, that's not what you want to press,
4:04
you'll be disappointed. This will completely close your program and start an entirely new debugging session from running the program from scratch.
4:12
So you might want to do that. In that case press this button but very likely your intention is I'm at a breakpoint I just want to keep going,
4:19
let that program keep working and we'll see where it goes from here. Don't press that button. You want this resume button down here.
4:27
Finally, when you're in this view, if your program is taking input or creating output in the terms of print statements,
4:34
warnings or things like that, that might go to a terminal, you won't see it here, you want the console. So in this exact same flow,
4:42
we were building up messages down here at the bottom and this is our wizard game In order to get to that step, we had to tell the wizard to attack.
4:51
So here you can see there's little green arrow question mark, there's more emphasis on where input is in the debugger type a.
4:58
It does the thing and so on. So if you want to see what's coming out of the console or especially if it
5:04
requires input, make sure to flip over to that tab.
5:06
It's not super obvious that it might be stopped because you're there waiting for some sort of input.