Modules and the Python Standard Library

Core path: 30 minutes

What actually happens when you write import?

Up to this point, most of the code you use has either lived in the same file or been built directly into Python's everyday language features.

Software does not scale by rewriting every useful behavior from scratch.

It grows by building on other code through boundaries we can name, inspect, and document.

Start with code you already trust Python to provide

import random

number = random.randint(1, 10)
print(number)

You did not implement a pseudo-random number generator in this file.

You asked Python to load an importable module named random, then called a function available through that module's namespace.

Read the layers:

YOUR PROGRAM
uses random.randint(...)
        ↓
random MODULE
provides reusable behavior
        ↓
PYTHON RUNTIME / STANDARD LIBRARY
makes that module available

Interactive model

See where imported code comes from

Pause motionReset layout

Your program can use your own modules, Python's standard library, and installed third-party packages, but all of them execute through the selected Python runtime.

YOUR PROGRAM main.py

YOUR MODULES helpers.py

STANDARD LIBRARY json · csv · pathlib

THIRD-PARTY PACKAGES installed with pip

SELECTED PYTHON interpreter / environment

React Flow

Press enter or space to select a node. You can then use the arrow keys to move the node around. Press delete to remove it and escape to cancel.

Press enter or space to select an edge. You can then press delete to remove it or escape to cancel.

Drag nodes to inspect the relationships. Motion shows the active path; the plain background keeps attention on the relationships instead of graph-paper decoration.

View static diagram

The arrows mean uses/imports/provides behavior across a code boundary. They are not an execution timeline where Python permanently moves from one box into another.

A module is an importable unit of Python code

At the beginner level, a very useful mental model is:

A .py file can act as a module when Python imports code from it.

A module can contain:

functions
classes
constants
other variables
imports

For example, a module named math provides functions and constants such as:

import math

print(math.sqrt(81))
print(math.pi)

The dot tells Python to look up a name inside the imported module's namespace.

The standard library is code that ships with Python

Python includes a large library of useful modules.

You have already touched several:

import json
import csv
from pathlib import Path
import random

These modules are not syntax built into every line of Python. They are reusable library code distributed with Python.

That is why official documentation matters. You are using APIs somebody else designed.

Importing is a runtime operation with search rules

When Python reaches:

import random

it has to resolve the name random to an importable module.

At a simplified level, Python searches locations available to the current interpreter/environment, loads the module if necessary, and binds the imported module to a name in your program.

This is why environment problems can produce:

ModuleNotFoundError

The source line may be correct while the selected interpreter cannot find the requested module/package in its import environment.

Week 11 is partly about making that hidden search layer visible.

Import styles change the names available in your code

Import the module

import math
print(math.sqrt(81))

Now the local name math refers to the module and sqrt is accessed through its namespace.

This style makes the source of the function obvious:

math.sqrt

Import one name

from math import sqrt
print(sqrt(81))

Now sqrt is available directly in the current module's namespace.

That can be concise, but the source of the name is less visible when reading a line far away from the import.

Use an alias

import random as rnd
print(rnd.randint(1, 10))

Aliases can be useful when a conventional shorter name improves readability.

Do not alias everything into cryptic two-letter names just because Python allows it.

Namespaces reduce collisions and expose ownership

Suppose two libraries both provide a function called load().

With module imports:

import storage
import config

storage.load()
config.load()

The module name tells the reader which responsibility owns each function.

Without that qualification, several generic names can become harder to distinguish.

Namespaces are not merely punctuation. They help organize names at scale.

Documentation is part of using a module

Professional developers do not memorize every argument and return type in every library.

A reliable workflow is:

1. identify the module/function you need;
2. read the official documentation;
3. inspect its function signature and return behavior;
4. write a tiny experiment;
5. only then integrate it into larger code.

For example, instead of assuming what random.randint(a, b) does with the endpoints, check the documentation or test the behavior.

The question is not:

Can I remember the API forever?

It is:

Can I find the authoritative contract and verify how it behaves in my environment?

A name collision can create a very confusing import

Imagine your project contains:

random.py
main.py

and main.py contains:

import random
print(random.randint(1, 10))

Depending on import resolution and project layout, your own random.py can shadow the standard-library module you expected.

Then the error looks absurd:

module 'random' has no attribute 'randint'

The fix is not reinstalling Python five times.

Inspect which module was actually imported:

print(random.__file__)

If it points into your project, you have evidence of the collision.

This is why naming your own files after standard modules is usually a bad idea.

Inspect a module instead of treating import as magic

import json

print(json.__name__)
print(json.__file__)

The exact path depends on your environment.

The useful observation is that json resolves to real code somewhere in the Python installation.

Then try:

import json

data = json.loads('{"name": "Nova", "score": 850}')
print(type(data))
print(data["name"])

Trace:

JSON string
  ↓ json.loads()
Python dictionary
  ↓ key lookup
"Nova"

The module gives your program a reusable translation mechanism you did not implement yourself.

Three source layers are coming together

By the end of Week 11, you will be working with code from:

YOUR PROJECT
main.py, storage.py, systems.py

PYTHON STANDARD LIBRARY
json, pathlib, csv, random

THIRD-PARTY PACKAGES
requests and other installed distributions

All may use import syntax. Their origin and installation lifecycle are different.

Lesson 2 builds your own module boundary. Lesson 3 introduces isolated third-party dependencies.