WEBVTT

1
00:00:00.080 --> 00:00:02.000
<v Speaker 1>Welcome to the Deep Dive. We're the show that helps

2
00:00:02.040 --> 00:00:05.400
<v Speaker 1>you navigate complex topics, giving you that essential clear view

3
00:00:05.440 --> 00:00:05.719
<v Speaker 1>from the.

4
00:00:05.719 --> 00:00:09.359
<v Speaker 2>Summit, and today we're looking at something many Python developers

5
00:00:09.400 --> 00:00:13.160
<v Speaker 2>grapple with, moving beyond basic tools like idl E.

6
00:00:13.160 --> 00:00:16.399
<v Speaker 1>Exactly, you hit a point where those simpler environments just

7
00:00:17.160 --> 00:00:19.559
<v Speaker 1>well they create friction right to slow you down.

8
00:00:19.640 --> 00:00:22.559
<v Speaker 2>I absolutely do so. Our deep Dive today is focused

9
00:00:22.559 --> 00:00:26.399
<v Speaker 2>squarely on Visual Studio Code or VS code. We've really

10
00:00:26.480 --> 00:00:30.000
<v Speaker 2>dug into resources like Visual Studio Code for Python programmers

11
00:00:30.039 --> 00:00:34.039
<v Speaker 2>to understand how it's specifically built for an efficient, productive Python.

12
00:00:33.679 --> 00:00:37.520
<v Speaker 1>Workflow, and our mission for you listening in is straightforward.

13
00:00:37.679 --> 00:00:39.399
<v Speaker 1>We want to give you a clear path through the

14
00:00:39.520 --> 00:00:44.799
<v Speaker 1>essential vs code features for Python. Think set up coding faster, debugging, smarter,

15
00:00:45.119 --> 00:00:45.960
<v Speaker 1>even collaborating.

16
00:00:46.039 --> 00:00:48.719
<v Speaker 2>Yeah, basically shortcutting your way to getting really comfortable and

17
00:00:48.799 --> 00:00:49.759
<v Speaker 2>effective with this editor.

18
00:00:49.880 --> 00:00:53.159
<v Speaker 1>Okay, so where do we start The foundation seems right.

19
00:00:53.399 --> 00:00:56.679
<v Speaker 2>Definitely, let's kick things off with just getting the environment

20
00:00:56.799 --> 00:00:57.640
<v Speaker 2>set up correctly.

21
00:00:57.799 --> 00:01:02.200
<v Speaker 1>First impressions of VS code, the UI. It looks simple,

22
00:01:02.560 --> 00:01:04.400
<v Speaker 1>almost sparse sometimes.

23
00:01:04.120 --> 00:01:07.079
<v Speaker 2>And that's deliberate. The whole philosophy is keeping your focus

24
00:01:07.120 --> 00:01:10.000
<v Speaker 2>on the code like ninety percent of the screen real estate.

25
00:01:10.480 --> 00:01:11.680
<v Speaker 2>That's for your source code.

26
00:01:11.719 --> 00:01:16.439
<v Speaker 1>You've got the activity bar, sidebar panels, status bar, but

27
00:01:16.480 --> 00:01:17.760
<v Speaker 1>they don't dominate.

28
00:01:17.480 --> 00:01:20.599
<v Speaker 2>Exactly the code is king. But here's the critical thing,

29
00:01:20.799 --> 00:01:22.079
<v Speaker 2>what we might call the.

30
00:01:22.120 --> 00:01:26.439
<v Speaker 1>Extension crux a right. VS code itself only really knows

31
00:01:26.480 --> 00:01:29.400
<v Speaker 1>web language is out of the box, JavaScript, HTML, that

32
00:01:29.439 --> 00:01:29.879
<v Speaker 1>sort of thing.

33
00:01:29.920 --> 00:01:33.359
<v Speaker 2>Precisely for Python development, you are entirely dependent on installing

34
00:01:33.400 --> 00:01:35.760
<v Speaker 2>the official Python extension from Microsoft.

35
00:01:35.879 --> 00:01:39.799
<v Speaker 1>So without that extension, yep, no proper Python support.

36
00:01:39.879 --> 00:01:44.400
<v Speaker 2>Nope, no advanced syntax highlighting, no intelligent code completion, and

37
00:01:44.439 --> 00:01:48.640
<v Speaker 2>crucially no debugging capabilities for Python. It's non negotiable.

38
00:01:48.640 --> 00:01:51.680
<v Speaker 1>You have to install it, okay, extension first, but even

39
00:01:51.719 --> 00:01:54.519
<v Speaker 1>before that you obviously need Python itself.

40
00:01:54.120 --> 00:01:57.280
<v Speaker 2>Installed correct, and the recommendation is Python three point six

41
00:01:57.400 --> 00:01:57.840
<v Speaker 2>or newer.

42
00:01:58.079 --> 00:02:01.079
<v Speaker 1>And a quick tip here, especially for Windows users that

43
00:02:01.319 --> 00:02:03.959
<v Speaker 1>add Python to path checkbox during installation.

44
00:02:04.079 --> 00:02:06.480
<v Speaker 2>Oh, absolutely check that box. Please check that box. Save

45
00:02:06.560 --> 00:02:11.680
<v Speaker 2>so much Hasselator does countless headaches avoided. Seriously. So, once

46
00:02:11.719 --> 00:02:14.520
<v Speaker 2>Python's installed, VS code is pretty good at finding it.

47
00:02:14.759 --> 00:02:15.919
<v Speaker 1>Where do you look to manage that?

48
00:02:16.120 --> 00:02:19.479
<v Speaker 2>The status bar bottom of the window, it'll show the

49
00:02:19.520 --> 00:02:21.960
<v Speaker 2>Python version you're currently using for that project, or it'll

50
00:02:22.000 --> 00:02:24.319
<v Speaker 2>prompt you to select one if it hasn't found one yet.

51
00:02:24.159 --> 00:02:27.800
<v Speaker 1>And when you click that, it shows you everything pretty much.

52
00:02:28.319 --> 00:02:33.319
<v Speaker 2>Global installs, virtual environments, conda environments, whatever it detects on

53
00:02:33.360 --> 00:02:35.680
<v Speaker 2>your system. It lists them so you can pick the

54
00:02:35.759 --> 00:02:36.439
<v Speaker 2>right path for.

55
00:02:36.439 --> 00:02:39.919
<v Speaker 1>Your workspace, which leads us nicely to the next absolutely

56
00:02:39.960 --> 00:02:41.840
<v Speaker 1>essential practice. Isolation.

57
00:02:42.120 --> 00:02:47.000
<v Speaker 2>Yes, cannot stress this enough. Always always use isolated environments,

58
00:02:47.120 --> 00:02:49.639
<v Speaker 2>virtual environments, conda environments, whatever your preference.

59
00:02:49.639 --> 00:02:50.680
<v Speaker 1>Why is that so critical?

60
00:02:50.759 --> 00:02:54.560
<v Speaker 2>Dependency conflicts? Project A needs library X version one point zero,

61
00:02:54.599 --> 00:02:56.800
<v Speaker 2>Project D needs library ex version two point five. If

62
00:02:56.840 --> 00:03:02.840
<v Speaker 2>you install everything globally, boom, things break horribly exactly. Isolation

63
00:03:03.039 --> 00:03:07.360
<v Speaker 2>keeps each project's dependency separate and manageable, and vs code

64
00:03:07.360 --> 00:03:10.159
<v Speaker 2>helps here too. It automatically detects when you create a

65
00:03:10.199 --> 00:03:13.680
<v Speaker 2>new virtual environment within your project folder and prompts you, hey,

66
00:03:13.719 --> 00:03:16.199
<v Speaker 2>found a new environment, want to use it for this workspace?

67
00:03:16.400 --> 00:03:18.439
<v Speaker 1>That's andy, takes away some of the manual.

68
00:03:18.120 --> 00:03:20.199
<v Speaker 2>Steps, makes it easier to do the right thing, which

69
00:03:20.240 --> 00:03:20.800
<v Speaker 2>is always good.

70
00:03:20.919 --> 00:03:26.800
<v Speaker 1>Okay, foundation laid, Python installed extension, active environment, isolated. Now

71
00:03:26.879 --> 00:03:33.280
<v Speaker 1>let's get into actually writing code faster. Part two productivity.

72
00:03:31.960 --> 00:03:35.520
<v Speaker 2>Leveraging that setup first up intell a Sense.

73
00:03:35.400 --> 00:03:37.800
<v Speaker 1>Microsoft's term for all the smart edding features.

74
00:03:37.840 --> 00:03:43.000
<v Speaker 2>Yeah, code completion, parameter info, quick info on hover, seeing

75
00:03:43.039 --> 00:03:46.360
<v Speaker 2>object definitions, all that stuff that saves you looking things

76
00:03:46.439 --> 00:03:47.120
<v Speaker 2>up constantly.

77
00:03:47.159 --> 00:03:48.560
<v Speaker 1>How do you trigger it? Just typing?

78
00:03:49.000 --> 00:03:52.240
<v Speaker 2>Often? Yes, Typing a dot after an object in Python

79
00:03:52.319 --> 00:03:55.759
<v Speaker 2>is a common trigger, or the classic stretrol plus space

80
00:03:55.800 --> 00:03:58.639
<v Speaker 2>bar usually brings up suggestions. It's like having reference stocks

81
00:03:58.719 --> 00:04:01.080
<v Speaker 2>right at your cursor keeps you in this low totally.

82
00:04:01.479 --> 00:04:04.439
<v Speaker 2>And this leads to I think our first real aha

83
00:04:04.919 --> 00:04:08.800
<v Speaker 2>moment for productivity, quick fixes and those intelligent imports. Uh.

84
00:04:08.919 --> 00:04:11.439
<v Speaker 1>The little light bulb I always likes seeing that means

85
00:04:11.439 --> 00:04:11.919
<v Speaker 1>help is on.

86
00:04:11.879 --> 00:04:15.400
<v Speaker 2>The way exactly. It pops up when vs code detects

87
00:04:15.400 --> 00:04:17.439
<v Speaker 2>something it might be able to fix for you. And

88
00:04:17.480 --> 00:04:21.120
<v Speaker 2>the Python Extensions ad imports quick fix is brilliant.

89
00:04:21.319 --> 00:04:22.079
<v Speaker 1>How does that work?

90
00:04:22.439 --> 00:04:26.759
<v Speaker 2>Say you type NP dot free because you're thinking NUMPI

91
00:04:27.000 --> 00:04:29.800
<v Speaker 2>or PD for pandas if you haven't imported them yet,

92
00:04:29.800 --> 00:04:32.959
<v Speaker 2>The light bulb appears, Click it and boom, it adds

93
00:04:33.079 --> 00:04:37.199
<v Speaker 2>important NUMPI as NP or import pandas as PD at

94
00:04:37.240 --> 00:04:38.319
<v Speaker 2>the top of your file for you.

95
00:04:38.439 --> 00:04:41.759
<v Speaker 1>Oh, that's nice. It knows the common abbreviations TF for

96
00:04:41.839 --> 00:04:42.639
<v Speaker 1>TensorFlow too.

97
00:04:42.879 --> 00:04:46.279
<v Speaker 2>Yeah, it handles the standard ones for major packages. Really

98
00:04:46.319 --> 00:04:48.120
<v Speaker 2>speeds up data science work for example.

99
00:04:48.279 --> 00:04:50.360
<v Speaker 1>Okay, but there was a catch to getting that really

100
00:04:50.399 --> 00:04:53.240
<v Speaker 1>slick import behavior. Wasn't there something about the language server?

101
00:04:53.399 --> 00:04:57.439
<v Speaker 2>Ah you remembered, Yes, good point. To get this specific, faster,

102
00:04:57.600 --> 00:05:01.319
<v Speaker 2>more intelligent behavior, including those quick imp you generally need

103
00:05:01.360 --> 00:05:04.120
<v Speaker 2>to switch away from the default Jedi language.

104
00:05:03.759 --> 00:05:06.319
<v Speaker 1>Server, right, You need to use the Microsoft Python language

105
00:05:06.319 --> 00:05:07.040
<v Speaker 1>server instead.

106
00:05:07.120 --> 00:05:10.079
<v Speaker 2>Correct, And that means going into your settings dot json

107
00:05:10.120 --> 00:05:13.800
<v Speaker 2>file and adding the line python dot jetti enabled dot false.

108
00:05:14.079 --> 00:05:16.639
<v Speaker 1>So slip a switch in the settings for better performance

109
00:05:16.680 --> 00:05:17.199
<v Speaker 1>and features.

110
00:05:17.439 --> 00:05:19.759
<v Speaker 2>Basically, yeah, it's a trade off you make to get

111
00:05:19.759 --> 00:05:22.439
<v Speaker 2>the enhanced experience worth doing in my opinion.

112
00:05:22.560 --> 00:05:26.839
<v Speaker 1>Okay, noted, So code is working, imports are fast. What

113
00:05:26.920 --> 00:05:31.040
<v Speaker 1>about making it clean, readable, maintainable?

114
00:05:31.560 --> 00:05:35.959
<v Speaker 2>Formatters and linters absolutely essential, especially in teams. Let's start

115
00:05:36.000 --> 00:05:41.240
<v Speaker 2>with formatters. Their job is purely about code style, consistency.

116
00:05:40.800 --> 00:05:45.000
<v Speaker 1>Making sure everyone's code looks the same, spaces, line breaks, quotes.

117
00:05:45.720 --> 00:05:49.759
<v Speaker 2>That's stuff exactly that It reduces cognitive load when reading code,

118
00:05:49.839 --> 00:05:53.360
<v Speaker 2>and maybe more importantly, it cuts down massively on merge

119
00:05:53.399 --> 00:05:56.079
<v Speaker 2>conflicts caused by trivial whitespace changes.

120
00:05:56.480 --> 00:05:58.879
<v Speaker 1>What are the main options? Vis code supports.

121
00:05:58.519 --> 00:06:01.720
<v Speaker 2>Three big ones. Autopep is the default. Its goal is

122
00:06:01.759 --> 00:06:04.079
<v Speaker 2>simply to make your code conform to the PEP.

123
00:06:03.879 --> 00:06:05.839
<v Speaker 1>Eight style guide, the official standard. Right.

124
00:06:05.879 --> 00:06:08.879
<v Speaker 2>Then you have Black. Black is opinionated, it's deliberately not

125
00:06:09.040 --> 00:06:09.839
<v Speaker 2>very configurable.

126
00:06:09.920 --> 00:06:10.720
<v Speaker 1>Sounds restrictive.

127
00:06:10.800 --> 00:06:12.759
<v Speaker 2>It is, but that's its selling point. If everyone on

128
00:06:12.800 --> 00:06:16.279
<v Speaker 2>the team uses Black style debates, just vanish. The code

129
00:06:16.279 --> 00:06:17.879
<v Speaker 2>will look the same period.

130
00:06:18.040 --> 00:06:20.480
<v Speaker 1>H in force consistency. I can see the appeal.

131
00:06:20.800 --> 00:06:24.480
<v Speaker 2>And the third is YAPF, yet another Python formatter from Google,

132
00:06:24.800 --> 00:06:27.439
<v Speaker 2>which is also opinionated, but maybe offers a bit more

133
00:06:27.439 --> 00:06:31.000
<v Speaker 2>configuration than Black. Choosing one is really a team or

134
00:06:31.079 --> 00:06:32.000
<v Speaker 2>project decision.

135
00:06:32.079 --> 00:06:35.680
<v Speaker 1>Okay, so formatters handle the Look what about linters? They

136
00:06:35.680 --> 00:06:37.639
<v Speaker 1>do mores right, they do.

137
00:06:37.759 --> 00:06:42.079
<v Speaker 2>Linters analyze your code for potential errors, style guide violations

138
00:06:42.199 --> 00:06:46.560
<v Speaker 2>beyond just formatting, and even bad coding practices or potential bugs.

139
00:06:46.720 --> 00:06:49.000
<v Speaker 1>They're like automated code reviewers kind of.

140
00:06:49.079 --> 00:06:52.839
<v Speaker 2>Yeah. The default is pilont. It's very comprehensive, checks for

141
00:06:52.959 --> 00:06:55.439
<v Speaker 2>errors and forces coding standards, looks for code smells.

142
00:06:55.519 --> 00:06:56.240
<v Speaker 1>What else is common?

143
00:06:56.399 --> 00:06:59.000
<v Speaker 2>Flake eight is popular. It combines a few other tools

144
00:06:59.040 --> 00:07:02.319
<v Speaker 2>and focuses heavily on PP eight compliance and logical errors.

145
00:07:02.600 --> 00:07:03.600
<v Speaker 2>And then there's bandit.

146
00:07:03.920 --> 00:07:05.480
<v Speaker 1>Band it sounds interesting.

147
00:07:05.600 --> 00:07:09.639
<v Speaker 2>It is. Ban It specifically looks for common security vulnerabilities

148
00:07:09.680 --> 00:07:13.560
<v Speaker 2>in your code, things like potential SQL injection, risks, hard

149
00:07:13.600 --> 00:07:18.160
<v Speaker 2>coded passwords, unsafe library usage. Really important if your code

150
00:07:18.160 --> 00:07:20.199
<v Speaker 2>handles sensitive data or runs.

151
00:07:19.920 --> 00:07:21.959
<v Speaker 1>In production and these aren't automatically yep.

152
00:07:22.160 --> 00:07:24.720
<v Speaker 2>Typically linting happens every time you save the file. You

153
00:07:24.759 --> 00:07:28.360
<v Speaker 2>get immediate feedback via squiggly lines and the problems panel.

154
00:07:28.399 --> 00:07:32.399
<v Speaker 1>Nice and quickly. What about refactoring cleaning up codes?

155
00:07:32.480 --> 00:07:35.759
<v Speaker 2>Structure vs Code has built in commands for that too,

156
00:07:35.959 --> 00:07:39.879
<v Speaker 2>things like extract variable or extract method to help you

157
00:07:39.959 --> 00:07:41.680
<v Speaker 2>break down complex functions.

158
00:07:41.720 --> 00:07:42.560
<v Speaker 1>Oh, that's useful.

159
00:07:43.079 --> 00:07:46.639
<v Speaker 2>And sort imports, which uses the ice Wort library behind

160
00:07:46.680 --> 00:07:50.079
<v Speaker 2>the scenes to automatically organize your import statements alphabetically and

161
00:07:50.120 --> 00:07:55.040
<v Speaker 2>group them again, great for consistency and readability. Plus snippets

162
00:07:55.120 --> 00:07:56.319
<v Speaker 2>for boilerplate code.

163
00:07:56.519 --> 00:07:58.639
<v Speaker 1>Okay, that covers a lot of ground for writing and

164
00:07:58.639 --> 00:08:05.079
<v Speaker 1>cleaning code. Shift gears Part three Advanced workflows Debugging has

165
00:08:05.120 --> 00:08:06.000
<v Speaker 1>to be top of the list.

166
00:08:06.079 --> 00:08:09.000
<v Speaker 2>Absolutely, Moving beyond just sticking print statements everywhere.

167
00:08:09.040 --> 00:08:12.639
<v Speaker 1>That's inefficient and missy and often doesn't tell you the

168
00:08:12.680 --> 00:08:13.680
<v Speaker 1>whole story exactly.

169
00:08:14.120 --> 00:08:17.120
<v Speaker 2>The core debugging concept in VS code, like most idase,

170
00:08:17.240 --> 00:08:19.519
<v Speaker 2>is the breakpoint, that little red dot you click in

171
00:08:19.519 --> 00:08:20.279
<v Speaker 2>the margin next.

172
00:08:20.160 --> 00:08:22.600
<v Speaker 1>To a line number, and that just pauses the program.

173
00:08:22.279 --> 00:08:25.279
<v Speaker 2>Instantly halts execution right before that line runs. Then you

174
00:08:25.279 --> 00:08:28.839
<v Speaker 2>can inspect everything variable values, the call stack, showing how

175
00:08:28.879 --> 00:08:31.240
<v Speaker 2>you got there, Step through the code line by line.

176
00:08:31.279 --> 00:08:32.559
<v Speaker 1>What are the main ways to step?

177
00:08:32.639 --> 00:08:37.080
<v Speaker 2>You've got the standard controls continue, run until the next breakpoint,

178
00:08:37.279 --> 00:08:39.919
<v Speaker 2>step over, run the current line, but step over function

179
00:08:40.000 --> 00:08:43.120
<v Speaker 2>calls without going inside. Step in two, go inside the

180
00:08:43.120 --> 00:08:45.960
<v Speaker 2>next function call, step out, finish the current function, and

181
00:08:45.960 --> 00:08:48.879
<v Speaker 2>return to the caller, plus restart and stop.

182
00:08:49.080 --> 00:08:53.240
<v Speaker 1>Pretty standard debugger controls. But the sources mentioned some specific

183
00:08:53.360 --> 00:08:56.840
<v Speaker 1>VS code features that sound like game changers. Log points.

184
00:08:57.000 --> 00:09:01.480
<v Speaker 2>Ah Yes, log points. This is our second aha moment.

185
00:09:01.600 --> 00:09:06.039
<v Speaker 2>I think they are genuinely transformative for certain debugging scenarios.

186
00:09:06.240 --> 00:09:08.559
<v Speaker 1>How do they differ from breakpoints? They look like a diamond,

187
00:09:08.559 --> 00:09:09.080
<v Speaker 1>not a dot.

188
00:09:09.279 --> 00:09:13.320
<v Speaker 2>Right, A breakpoint stops execution, a log point does not. Instead,

189
00:09:13.399 --> 00:09:15.600
<v Speaker 2>when the program hits a log point, it just outputs

190
00:09:15.600 --> 00:09:18.000
<v Speaker 2>a message to the debug console and keeps running.

191
00:09:17.799 --> 00:09:21.080
<v Speaker 1>So like a print statement, but without modifying the code exactly.

192
00:09:21.159 --> 00:09:23.360
<v Speaker 2>Imagine you have a long running process, maybe something in

193
00:09:23.360 --> 00:09:25.720
<v Speaker 2>a loop, and you want to track how a variable

194
00:09:25.799 --> 00:09:28.000
<v Speaker 2>changes over time. But you don't want to stop the

195
00:09:28.000 --> 00:09:30.879
<v Speaker 2>program every single iteration or clutter your.

196
00:09:30.720 --> 00:09:33.799
<v Speaker 1>Code with temporary prints, you have to remember to remove precisely.

197
00:09:34.159 --> 00:09:36.080
<v Speaker 2>With a log point, you write click in the margin,

198
00:09:36.240 --> 00:09:38.919
<v Speaker 2>choose ad log point, and type a message. You can

199
00:09:39.000 --> 00:09:42.480
<v Speaker 2>even include variable values directly in the message using curly

200
00:09:42.519 --> 00:09:45.200
<v Speaker 2>braces like current value my variable.

201
00:09:45.360 --> 00:09:48.480
<v Speaker 1>Oh wow, so you can monitor state without halting anything.

202
00:09:48.600 --> 00:09:50.039
<v Speaker 1>That's really powerful.

203
00:09:50.120 --> 00:09:54.080
<v Speaker 2>It's fantastic for diagnosing issues in complex loops, asynchronous code,

204
00:09:54.159 --> 00:09:57.080
<v Speaker 2>or anywhere you need to observe behavior over time without

205
00:09:57.200 --> 00:09:58.279
<v Speaker 2>constant interruption.

206
00:09:58.480 --> 00:10:01.600
<v Speaker 1>Okay, log points for NonStop monitoring. What about making break

207
00:10:01.720 --> 00:10:05.279
<v Speaker 1>points smarter? Conditional breakpoint?

208
00:10:05.440 --> 00:10:08.600
<v Speaker 2>Yes, this is about adding precision. Sometimes a line of

209
00:10:08.600 --> 00:10:11.120
<v Speaker 2>code gets hit thousands of times in a loop, but

210
00:10:11.159 --> 00:10:13.240
<v Speaker 2>you only care about the one time when a specific

211
00:10:13.240 --> 00:10:14.120
<v Speaker 2>condition is met.

212
00:10:14.320 --> 00:10:16.840
<v Speaker 1>Like maybe a bug only happens when a counter variable

213
00:10:16.840 --> 00:10:18.000
<v Speaker 1>reaches one thousand.

214
00:10:17.960 --> 00:10:21.919
<v Speaker 2>Exactly, or maybe when a specific user ID say studentit

215
00:10:21.960 --> 00:10:25.320
<v Speaker 2>equals zero zero zero three is being processed. Instead of

216
00:10:25.320 --> 00:10:28.240
<v Speaker 2>setting a normal breakpoint and hitting continue nine hundred and

217
00:10:28.320 --> 00:10:30.480
<v Speaker 2>ninety nine times, you set a conditional one.

218
00:10:30.480 --> 00:10:31.559
<v Speaker 1>Well, how do you set the condition?

219
00:10:31.879 --> 00:10:35.600
<v Speaker 2>Right click the breakpoint, choose edit breakpoint, and enter an expression.

220
00:10:36.320 --> 00:10:39.639
<v Speaker 2>It can be based on hunt, hitcount ten, or any

221
00:10:39.639 --> 00:10:43.960
<v Speaker 2>Python expression that evaluates to true or false. Varioblex some value.

222
00:10:44.039 --> 00:10:45.960
<v Speaker 2>End status equals error.

223
00:10:46.440 --> 00:10:49.639
<v Speaker 1>So the debugger only pauses if that condition is true

224
00:10:49.639 --> 00:10:51.360
<v Speaker 1>when the line is reached precisely.

225
00:10:51.480 --> 00:10:54.159
<v Speaker 2>Surgical debugging saves an immense amount of time.

226
00:10:54.279 --> 00:10:57.120
<v Speaker 1>Okay, so we're paused either at a normal breakpoint or

227
00:10:57.159 --> 00:11:00.000
<v Speaker 1>a fancy conditional one. What's the debug console? You make?

228
00:11:00.519 --> 00:11:05.279
<v Speaker 2>Ah, the debug console. It's essentially a RPL a read

229
00:11:05.320 --> 00:11:08.960
<v Speaker 2>evil print loop, but it's connected directly to your paused

230
00:11:09.000 --> 00:11:10.240
<v Speaker 2>program's current state.

231
00:11:10.639 --> 00:11:12.559
<v Speaker 1>So I can type Python code in there, yes.

232
00:11:12.600 --> 00:11:15.080
<v Speaker 2>And it executes within the context of where your program

233
00:11:15.120 --> 00:11:18.399
<v Speaker 2>is paused. You can inspect variable values just by typing

234
00:11:18.399 --> 00:11:20.799
<v Speaker 2>their names. You can call functions that are available in

235
00:11:20.799 --> 00:11:21.200
<v Speaker 2>that scope.

236
00:11:21.240 --> 00:11:23.799
<v Speaker 1>And the real power you mentioned was changing things.

237
00:11:24.000 --> 00:11:26.840
<v Speaker 2>That's the killer feature. Let's say you're paused and you

238
00:11:26.919 --> 00:11:30.120
<v Speaker 2>inspect a variable, maybe a dictionary, and realize it's missing

239
00:11:30.200 --> 00:11:32.639
<v Speaker 2>a key or has the wrong value.

240
00:11:32.279 --> 00:11:34.440
<v Speaker 1>Which is causing the bug further down right.

241
00:11:34.679 --> 00:11:38.039
<v Speaker 2>Normally, you'd have to stop debugging, go edit the source code,

242
00:11:38.240 --> 00:11:41.279
<v Speaker 2>restart the whole application. Get back to that point could take.

243
00:11:41.159 --> 00:11:43.440
<v Speaker 1>Ages, especially with complex setups.

244
00:11:43.480 --> 00:11:46.639
<v Speaker 2>But with a debug console RPL, while paused, you can

245
00:11:46.759 --> 00:11:49.480
<v Speaker 2>just type code to fix the variable right there, like

246
00:11:49.600 --> 00:11:53.000
<v Speaker 2>mighty missing key all gize some value or counter zero.

247
00:11:53.440 --> 00:11:55.720
<v Speaker 1>You modify the program state live while.

248
00:11:55.559 --> 00:11:58.679
<v Speaker 2>It's paused exactly. You apply the potential fix, and the

249
00:11:58.759 --> 00:12:02.200
<v Speaker 2>RPL then hit Can you if the program now runs

250
00:12:02.200 --> 00:12:05.399
<v Speaker 2>correctly past the point where it previously failed. You've just

251
00:12:05.480 --> 00:12:07.759
<v Speaker 2>confirmed your fix without restarting anything.

252
00:12:07.879 --> 00:12:10.440
<v Speaker 1>That sounds incredibly efficient for testing fixes.

253
00:12:10.519 --> 00:12:13.919
<v Speaker 2>It transforms debugging from a slow edit run fail cycle

254
00:12:14.000 --> 00:12:16.039
<v Speaker 2>into an interactive troubleshooting session.

255
00:12:16.080 --> 00:12:20.399
<v Speaker 1>It's amazing, Okay, shifting from solo debugging to teamwork. Source

256
00:12:20.440 --> 00:12:23.840
<v Speaker 1>Control vs Code integrates with get pretty.

257
00:12:23.600 --> 00:12:27.159
<v Speaker 2>Tightly, very tightly, assumes you have GET installed version two

258
00:12:27.159 --> 00:12:30.000
<v Speaker 2>point zero or later. The source control view the little

259
00:12:30.080 --> 00:12:32.840
<v Speaker 2>branching icon constantly tracks your changes, so the.

260
00:12:32.840 --> 00:12:34.919
<v Speaker 1>U for untracked M for modified files.

261
00:12:35.000 --> 00:12:38.840
<v Speaker 2>Yeah, make staging, committing, viewing difts really straightforward.

262
00:12:38.919 --> 00:12:41.600
<v Speaker 1>Right within the editor and for get ub users, there's

263
00:12:41.679 --> 00:12:43.120
<v Speaker 1>that specific extension.

264
00:12:43.240 --> 00:12:46.600
<v Speaker 2>Oh yeah, the GitHub pull requests and issues extension. It's

265
00:12:46.639 --> 00:12:49.759
<v Speaker 2>almost essential if you live on GitHub. You can manage

266
00:12:49.799 --> 00:12:54.120
<v Speaker 2>pull requests, review code at comments, approve, merge, create issues,

267
00:12:54.720 --> 00:12:55.600
<v Speaker 2>all without leaving.

268
00:12:55.720 --> 00:12:58.360
<v Speaker 1>Vs Code automates a lot of the command line get dance.

269
00:12:58.559 --> 00:13:00.840
<v Speaker 2>It really does streamline the whole workflow.

270
00:13:00.919 --> 00:13:05.080
<v Speaker 1>And one more collaboration tool, Live Share. What's the idea there?

271
00:13:05.200 --> 00:13:08.559
<v Speaker 2>Think Google Docs, but for your entire coding environment.

272
00:13:08.799 --> 00:13:09.279
<v Speaker 1>Seriously.

273
00:13:09.440 --> 00:13:12.120
<v Speaker 2>Yeah, as a host, you can start a live share

274
00:13:12.159 --> 00:13:15.200
<v Speaker 2>session and send a link to guests. They join your

275
00:13:15.200 --> 00:13:17.399
<v Speaker 2>session right from their own vs code.

276
00:13:17.120 --> 00:13:18.960
<v Speaker 1>Instance, and they can see my code.

277
00:13:18.960 --> 00:13:21.399
<v Speaker 2>They can see your code, see your cursor moving, see

278
00:13:21.399 --> 00:13:24.039
<v Speaker 2>your edits in real time. You can grant them read

279
00:13:24.080 --> 00:13:27.120
<v Speaker 2>only access or full collaborative editing rights.

280
00:13:26.919 --> 00:13:29.080
<v Speaker 1>So we could literally type in the same file at

281
00:13:29.080 --> 00:13:30.360
<v Speaker 1>the same time you could.

282
00:13:30.679 --> 00:13:32.799
<v Speaker 2>You can also share your server reports so they could

283
00:13:32.879 --> 00:13:35.799
<v Speaker 2>interact with a web app you're running locally, and even

284
00:13:35.879 --> 00:13:40.080
<v Speaker 2>share a terminal session again read only or fully collaborative.

285
00:13:40.200 --> 00:13:43.600
<v Speaker 1>Wow, that's like remote pair programming on steroids.

286
00:13:43.879 --> 00:13:49.240
<v Speaker 2>It's incredibly powerful for mentoring, debugging together, or just collaborating closely.

287
00:13:49.279 --> 00:13:50.919
<v Speaker 2>When you're not physically in the same room.

288
00:13:51.000 --> 00:13:54.440
<v Speaker 1>Okay, so stepping back, we've covered a lot setting up

289
00:13:54.440 --> 00:13:58.720
<v Speaker 1>the foundation right with Python, the extension isolated environments.

290
00:13:58.279 --> 00:14:03.000
<v Speaker 2>Then boosting productivity within tellis us, smart imports, formatters.

291
00:14:02.399 --> 00:14:08.240
<v Speaker 1>Linters, and finally these really advanced workflows log points, conditional breakpoints,

292
00:14:08.440 --> 00:14:11.960
<v Speaker 1>the interactive to bug console r EPL, integrated GIT and

293
00:14:12.039 --> 00:14:12.679
<v Speaker 1>live share.

294
00:14:13.240 --> 00:14:16.080
<v Speaker 2>It really paints a picture of vs code as much

295
00:14:16.120 --> 00:14:18.759
<v Speaker 2>more than a text editor. It's a comprehensive toolkit for

296
00:14:18.799 --> 00:14:19.600
<v Speaker 2>Python development.

297
00:14:19.799 --> 00:14:23.200
<v Speaker 1>We saw just how powerful those debugging tools, log points

298
00:14:23.240 --> 00:14:25.879
<v Speaker 1>the RPL are for figuring out what's happening in a

299
00:14:25.879 --> 00:14:28.919
<v Speaker 1>script running on your own machine. But the source material

300
00:14:28.960 --> 00:14:33.720
<v Speaker 1>also highlighted vs code's reach into bigger environments containers Jupiter notebooks,

301
00:14:33.759 --> 00:14:37.399
<v Speaker 1>web frameworks like Flask and Jango, even deploying to cloud

302
00:14:37.399 --> 00:14:39.679
<v Speaker 1>platforms like Azuo functions.

303
00:14:39.240 --> 00:14:42.320
<v Speaker 2>That integration is key. It aims to provide a consistent

304
00:14:42.399 --> 00:14:44.159
<v Speaker 2>experience across different contexts.

305
00:14:44.360 --> 00:14:47.240
<v Speaker 1>So here's the final thought to chew on. Imagine using

306
00:14:47.279 --> 00:14:52.159
<v Speaker 1>those same sophisticated tools log points to monitor state without stopping,

307
00:14:52.720 --> 00:14:56.200
<v Speaker 1>conditional breakpoints to zero in on rare events, the debug

308
00:14:56.240 --> 00:14:59.480
<v Speaker 1>console r EPL to test fixes live okay, but you're

309
00:14:59.519 --> 00:15:01.759
<v Speaker 1>doing it not just on a local script, but on

310
00:15:01.840 --> 00:15:04.679
<v Speaker 1>code running inside a Docker container, or within a complex

311
00:15:04.799 --> 00:15:07.799
<v Speaker 1>Jupiter notebook, or even attached to a process running remotely

312
00:15:07.799 --> 00:15:10.399
<v Speaker 1>on a cloud service like Azure Functions, all from your

313
00:15:10.399 --> 00:15:12.240
<v Speaker 1>familiar editor interface.

314
00:15:12.039 --> 00:15:15.879
<v Speaker 2>Right, connecting that deep debugging power directly to these complex,

315
00:15:15.960 --> 00:15:18.279
<v Speaker 2>often remote production like environments.

316
00:15:18.679 --> 00:15:21.440
<v Speaker 1>What does that capability truly mean for your ability to

317
00:15:21.480 --> 00:15:25.399
<v Speaker 1>diagnose and squash bugs in those really challenging multi component

318
00:15:25.399 --> 00:15:27.080
<v Speaker 1>applications we often deal with today.

319
00:15:27.360 --> 00:15:30.559
<v Speaker 2>It drastically shrinks the feedback loop right produces the friction

320
00:15:30.679 --> 00:15:32.960
<v Speaker 2>of diagnosing problems in those complex systems.

321
00:15:33.000 --> 00:15:36.440
<v Speaker 1>Exactly. It bridges the gap between your powerful local editor

322
00:15:36.679 --> 00:15:40.000
<v Speaker 1>and the realities of modern deployment. So the question for

323
00:15:40.039 --> 00:15:44.440
<v Speaker 1>you is what complex, real world bug, maybe one that's

324
00:15:44.440 --> 00:15:47.399
<v Speaker 1>been nagging you, could you finally tackle if you brought

325
00:15:47.399 --> 00:15:49.679
<v Speaker 1>the full power of log points and the debug console

326
00:15:49.720 --> 00:15:50.919
<v Speaker 1>alreadypl to bear on.

327
00:15:50.879 --> 00:15:53.559
<v Speaker 2>It something to think about. It could save you a

328
00:15:53.559 --> 00:15:56.480
<v Speaker 2>lot of time and frustration. Thanks for diving deep with

329
00:15:56.559 --> 00:15:57.120
<v Speaker 2>us today.