### Part 1: What's the problem? We'll start by looking at the problem that `import` tries to solve: allowing python code in one module access to code in another module. I'll introduce the idea of a namespace and draw an equivalence between a namespace and a dictionary as an example of a simple lookup table. ### Part 2: How do we solve it? We'll examine possible ways to allow code from one module to access code in another module. I'll suggest different strategies and discuss their advantages and disadvantages. I'll show that those design decisions were made in other languages. For example, we could insert all the code from Module B into Module A at compile-time. The strengths: easy for the programmer to reason about (and others). The weaknesses: namespace collision and a rigid import system that can't change at runtime (and others). The analogy: C's `#include`. There will be three of these sections, each taking about three minutes to discuss. ### Part 3: Home to python This section will transition from the last by proposing a solution to code-sharing that mirrors python's actual implementation of `import`. We'll discuss strengths and weaknesses of the model. I will briefly cover the steps of the import process: finding a module and returning a loader; checking in sys.modules for the module object; initializing a new module object, if needed; and executing the module's code object in the context of the new module object just created, if needed. ### Part 4: An artisan hand-crafted module I will follow the steps required to create a module by hand, without using `import`.