Standard Library Categories — When to Use What

Python's standard library is the set of hundreds of modules you can use with just import — no pip install required. This article organizes the whole thing into 7 categories so you can see the layout at a glance.

What the Standard Library Is — Modules That Ship with Python

The standard library is the collection of modules that work the moment you install Python. Things like math, os, and json are available with just import — you never have to run pip install for them.

There are situations where the standard library isn't enough, but trying the standard one first usually pays off in the long run. Here's why.

• No extra install needed, so it runs anywhere — internal servers, CI, Docker containers, even the browser runtime this series uses
• Version management is easy — once you fix the Python version, the standard library version is also fixed automatically
• Battle-tested and stable — the standard library evolves while keeping strict backward compatibility, so code you wrote years ago still works

The 7 Categories by Use Case

The standard library has hundreds of modules, but grouping them into 7 categories by purpose makes it much easier to know where to look. This series follows the same order, walking through each category one by one from top to bottom.

Each category lists multiple modules because the goal is the same but the angle is different. For example, in category B, both random and secrets generate random numbers, but random is for games and test data, while secrets returns strong random numbers suitable for security use cases like password reset tokens. This series goes through each category and sorts out these similar-but-different modules so you know which one to reach for.

How to Write import — Conventions That Avoid Name Clashes

There are several ways to write import when calling into the standard library (covered in detail in the previous article). Each has its perks and pitfalls, so you pick based on the situation. Here are the four common patterns.

The import math form shows where each name came from at the call site, so you don't get lost when re-reading the code later. On the other hand, the from package import function form drops the module-name prefix (the part attached before the function name, like the math. in math.sqrt), which lets you write things compactly like datetime(2024, 1, 1).

Avoid from x import star as a rule

Writing from os import * to pull in every name can silently overwrite same-named functions defined elsewhere. For example, os.open() and the built-in open() are different things, but writing from os import * replaces the built-in open with os.open and breaks file reading and writing. Avoid it for both your own modules and standard library ones — it's the safe move.

Standard Libraries That Don't Run in the Browser — How This Series Handles Them

The exercises in this series run on a browser-based Python runtime (MicroPython or Pyodide). Most of the standard library works fine, but anything that needs OS threads or processes simply can't be made to work — the browser sandbox doesn't allow it. sys.argv (the mechanism for receiving command-line arguments) also works on a real machine but doesn't work in the browser, since there's no way to pass arguments in. For these, we cover the concepts with diagrams so you can recall them quickly when you write the code on a real machine.

Why we still cover diagram-only topics

In real work, you'll definitely run code on an actual OS at some point. When that happens, knowing the concepts behind threading vs. multiprocessing or running a command via subprocess makes a huge difference in how easily you can take that first step. This series doesn't skip topics just because they don't run in the browser — instead, we diagram out the parts that can't run, so you can recall them when you actually need to write the code.