Unit 11: Modules, Libraries & Packages

import looks like one keyword. Behind it is an entire dependency boundary.

Your program may import code you wrote, code distributed with Python, or a third-party package installed into one particular environment. Those sources can use similar syntax while having different ownership, installation, update, and failure behavior.

Trace where code comes from

This Unit separates three layers:

PROJECT CODE
Python files/modules you own

STANDARD LIBRARY
modules distributed with Python

THIRD-PARTY DEPENDENCIES
packages installed into an environment

You will create your own module, use namespaces, inspect import resolution, work with standard-library modules, create or use a virtual environment, install a bounded dependency, and diagnose import failures.

One deliberately confusing failure matters here: naming your own file after a module you intended to import. The resulting shadowing problem teaches why module identity must be inspected rather than assumed.

Dependency receipt

Before you move on, prove where one imported module came from and which Python environment can import it. Record the import statement, module path or package evidence, selected interpreter/environment, and one failure produced from the wrong environment or wrong module name.

Dependencies are architecture. Treat them as visible parts of the system.