Command Palette

Search for a command to run...

Hectal
Phase 6Intermediate7 of 18 in Python

Modules, Packages and Projects

Split code across files, import it, organise it into packages, tour the standard library, and learn the tools and layout of a real, shippable Python project.

Until now your programs lived in one file. Real programs live in many: a file is a module, a folder of modules is a package, and import is the glue. This phase explains exactly what import does, where Python looks for files, and the mistakes that trip up almost everyone (a file named random.py, a circular import, a relative import that will not run).

You will tour the standard library, the large set of ready-made tools that ships with Python, and learn how to read its documentation. Then you will meet the world outside it: PyPI (the public shop for Python packages), virtual environments (a private folder of packages for each project), pip (the installer), and uv, the modern all-in-one tool. From Topic 6.5 on you will type commands into a terminal, and that topic explains what that is, step by step. You will learn what pyproject.toml is, how version rules work, and why a lock file makes a project reproducible.

The phase ends with the shape of a real project (the src/ layout, tests, entry points, config kept out of code) and how a package is built into a wheel and published, including the habits that keep you safe from bad packages. Many examples here write small files and import them live, so you can watch the machinery work. The tools that need a real terminal (pip, uv) are shown as commands, with short outputs.

0/9 · 0%
9 topics ~5 h 34 code blocks & diagrams
Start with the first topic
1
6.1

import: Using Code from Other Files

import loads another module and gives you a name for it. Python runs the module's file once, the first time it is imported, and keeps the result in sys.modules so that every later import is instant and shares the same module object.

35 min 1 diagram 4 code practice

2
6.2

Writing Your Own Modules

Any .py file is a module you can import. The line if __name__ == "__main__": lets one file work both as a program and as a library, and sys.path is the list of folders Python searches, which is why a file named after a standard module can break your program.

29 min 3 code practice

3
6.3

Packages and __init__.py

A package is a folder of modules that you import as one unit. Its __init__.py runs on import and decides what the package shows to the outside, absolute imports name the full path from the top, relative imports use dots, and circular imports are fixed by changing who imports whom.

29 min 4 code practice

4
6.4

A Tour of the Standard Library

Python ships with hundreds of ready-made modules: maths, randomness, dates and time zones, the operating system, iteration tools, statistics and JSON. Knowing what exists, and how to read the documentation, saves you from rewriting what is already built, tested and fast.

34 min 1 diagram 3 code practice

5
6.5

Virtual Environments and pip

A virtual environment is a private folder of installed packages for one project, so projects with different needs do not fight. pip installs packages from PyPI into it, and a requirements.txt file records what to install again.

29 min 1 diagram 3 code practice

6
6.6

Modern Project Tooling with uv

uv is one fast tool that replaces pip, venv, pyenv and pipx: it creates projects, installs the right Python, adds dependencies, writes an exact uv.lock, and runs your code in the project's environment.

28 min 1 diagram 3 code practice

7
6.7

pyproject.toml and Dependencies

pyproject.toml is the one standard file that describes a Python project: its name, version, supported Python, dependencies (with version rules), optional extras, development-only groups, commands and tool settings.

28 min 1 diagram 2 code practice

8
6.8

Laying Out a Real Project

A real project has a predictable shape: code in src/<package>/, tests in tests/, a pyproject.toml, a README, a .gitignore, and settings and secrets kept out of the code. It runs with python -m package or an installed command.

29 min 1 diagram 2 code practice

9
6.9

Building and Publishing a Package

To share a package you build it into a wheel (a ready-to-unpack zip) and an sdist (source archive) with a build backend, then upload both to PyPI, trying TestPyPI first. As a user, treat every dependency as code you are running: pin versions, use hashes, check names and review new packages.

30 min 1 diagram 3 code practice

Practise this phase

Hands-on exercises: write the code, run it, and press Check to have it tested automatically.

1

Classify a requirements line

Write a function pin_status(line). Its input line is one line of a requirements.txt file, written as text, for example "requests==2.32.3".

Intermediate
2

Compare versions as numbers

Write parse_version(text) that turns "2.10.0" into the tuple (2, 10, 0).

Intermediate
3

Write a module and import it

Use Path("greeter.py").write_text(...) to create a file greeter.py. The file must define a function greet(name) that returns "Hello, ", then the name, then "!". For example, greet("Asha") returns Hello, Asha!.

Intermediate
4

Read a pyproject.toml

Write project_info(text). Its input text is the whole content of a pyproject.toml file, as one string. Parse it with tomllib.loads and return a tuple (name, dependencies): the project name and the dependencies list, both from the [project] table.

Intermediate
5

Flag look-alike package names

Write is_lookalike(name, popular) that returns True when name is not in the list popular but is very close to one of its entries, using difflib.get_close_matches with cutoff=0.8.

Intermediate