Creating modules | Intro to CS - Python | Khan Academy

We've been writing our code all in a single file, but as our programs get longer, our main logic tends to get buried underneath all of our function definitions, which can make the program hard to read. So, easy solution: what if we just took all those function definitions and move them somewhere else? That means organizing our code into modules.

To create a module, we just make a new file with a .py file extension. File extensions tell the computer how to interpret the file's contents, like .mp4 is a video and .py is Python code. We'll name this file arcade.py because it's meant to contain functionality for an arcade game, and then we'll just move all those function definitions in here.

If I run the program now, I get a name error because the computer doesn't know where to find those functions anymore. It may seem obvious to us that there's another file over here, but the computer doesn't put two and two together. It only does exactly what we tell it to do. So, if we want the computer to be aware of the arcade module when it runs the program, we need to import it.

Anytime we call one of its functions here, then we need to prefix it with the module name. All right, that concept is pretty straightforward. We just have our code in multiple files now, but let's unpack how exactly this all works.

Even though our program logic may be spread across multiple files, when we run a program, we can only ever specify a single file to execute. We call this the entry point or main logic. By convention in Python, we name this file main.py. You may have noticed that in the Con Academy IDE, the default file is always named main.py. When we press the Run button, this is the file that executes.

We can build up a program by having a function in one module call a function in another module, which imports another module, and so on and so on. But for any code to be executed, it needs to be triggered somewhere along the chain from that entry point file.

Okay, what about this import statement? How exactly does that work? When the computer executes an import statement, it jumps execution to the specified module. When it's done there, it'll jump execution back to the importing module and pick up from where it left off. From the computer's perspective, importing a module is effectively the same as copying and pasting all the contents of that file where the import statement appears.

But there's one key difference: the scope of function and variable names are scoped to the module that they're defined in. This just basically adds another layer. In the computer's memory, all those function names are filed under the module name. That's why if we call get_score in main.py without the arcade in front of it, we get a name error, because the computer can't find that name in Main's global scope.

By putting the arcade in front of it, we make it a two-step lookup. First, the computer looks in its memory for the arcade namespace, and then in that scope, it looks up get_score. Module scope means that as a programmer, I don't have to worry about what other programmers or myself yesterday are naming their functions in other files. We can both name our functions get_score because they'll exist in different scopes.

Note that we typically only put function definitions inside a module because the net effect of executing that is just that the computer has learned some new tasks. If I add a print statement indented at the top level of this file, it executes anytime I import this module. If that module imports another module, which imports another module, and all of them have these top-level print statements, it becomes very difficult to trace where that output is coming from.

So why use modules? Well, they're really just a convenience for the programmer. We break down our task into functions, and then we group those functions into modules. Well-written modules make programs easy to navigate because if I want a piece of functionality related to inventory management, I would know to look in the inventory module.

They also make code more reusable because I can package a bunch of relative functionality into a module and then import it in multiple places. And they let us focus on one thing at a time as we're building. When I'm working in main.py, I can think about my program at a high level and just work on how all the pieces fit together. And when I'm working in inventory.py, I can forget about all that and just focus on the details of how inventory management works.