Local and global scope

0:00- [Instructor] What do you think happens when I run this program? Does it print 0, 4 or raise some kind of error? To find out, let's explore variable scope. The scope of a variable describes the region of the program where we can access it. When we run this program, the computer will store the instructions for the get fall damage function in short-term memory.

0:20Then it'll store the variables max damage, damage and height. These all exist in what we call global scope. Because we define them at the top level of the program. The computer stores them in that base level in its short-term memory, so they can be accessed anywhere in the program.

0:37They're global. Then we execute this function call. So the computer starts off by creating a new stack frame, which remember is just a separate region of short-term memory. The parameter height, and then this damage gets stored in that new stack frame. Notice that these don't get stored in that base global level, so we don't overwrite the value of this existing global damage.

1:02Instead, we're creating new damage and height variables in a different scope. We call this local scope because it's local to this region of memory. As soon as the function call returns, that stack frame gets popped off, so all those local variables disappear. By the time we get to this last print statement, we only have the global damage available.

1:24So this print zero. What does this tell us? Anytime we assign a variable as a part of a function call, that variable gets stored on that local stack frame. That means we can't use functions to update global state. The only reliable way that we can communicate information out of a function is through the return value.

1:44So instead of trying to update the global variable damage, we can just return out the result of our damage calculation. When we exit out of that function call, we're back in global scope so we can store that return value. Okay, but why is Python like this? Technically, we can force Python to access the variable in global scope instead.

2:04We put the keyword global, and the name of the variable, but we should almost never do this. Python defaults to local scope for a reason. By the time we're finished, our program may have tons and tons of function definitions. If every variable in every function was in global scope, then every variable, and every function parameter would have to have a global unique name.

2:27We couldn't reuse anything. That becomes incredibly difficult to enforce. If I have thousands of lines of code spread across tons of different files. Anytime I wanna create a new variable, I'd have to first check if that name is used anywhere else in the program, otherwise my function, and that other function will start conflicting where we're overriding each other's values, which is not what we wanted here.

2:48Local scope lets us avoid this problem because we don't need to worry about the larger program state. We can reuse whatever needs we want inside our local function scope. Let's say I changed the value of height to 100. We still have the same four names in global scope, and the same two names in local scope.

3:05So what happens when we access max damage inside the function? Well, it turns out, while we can't modify the value of a global variable from local scope, we can view the value. When the computer looks up a name, it starts its search in the closest scope. Here it searches the local stack frame first for the name max damage.

3:26If it doesn't find it in memory there, it moves its search to the next closest in closing scope. So now it'll try to look up max damage in global scope, and once it finds it, it uses that value. If it hadn't found it, it would raise a name error when it ran outta scopes to search.

3:44Now this can be convenient, but it's still not recommended. This function can't guarantee that there exists a global variable named max damage, and colleagues of this function may not realize that's a requirement. So we are just asking for future bugs. It's much safer if I only rely on information passed in through the function parameters.

4:06Instead of accessing the global max damage, I can add a second parameter that takes in that max damage threshold. That way I can enforce that callers of my function think about what value max damage should have. Instead of just hoping that some global variable has been set correctly.

4:23Our key takeaways, names defined at the top level of a program are in global scope and names defined inside a function are local scope. There are ways to cross these boundaries, but in good programming practice, we should avoid it as much as possible. Instead, think of your functions like input/output machines.

4:41We can communicate information in from an enclosing scope at the beginning through the function arguments, and we can communicate information out to the enclosing scope at the end through the return value. Anything that happens in the middle is a local secret.