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