Capstone: type an untyped module
P31.typing.03 · Audience: guest, it-ml, language-pro · Prerequisites: Generics, Protocols & ParamSpec
This is the typing half of the P30/P31 capstone. In
P30's capstone you wrote the tests that pin a
module's behaviour; here you add the types. Together they are the discipline's
promise: an untested, untyped module made robust — green pytest, green mypy,
green ruff.
ⓘ Concept: Make the module type-check
The Cart class works but is completely untyped. Annotate
every method (precise parameter and return types) and declare
the items attribute as list[tuple[str, float, int]],
without changing any behaviour. The grader runs a
type contract — typing.get_type_hints over your
annotations — and re-checks that the cart still behaves. Types that lie, or a
broken cart, fail.
Why it matters — Annotating existing code is the daily reality of adding types to a codebase — and the capstone that turns 'I know the syntax' into 'I can make a module robust'.
Ask the mentor about this module
Ask a question about this content. The mentor explains and grounds its answer in what you are studying; asking is recorded as a learning signal, not a grade.
🎓 Practice ladder
1 graded rung · ~25 minTake the untyped Cart to a green type contract — the typing half of
the capstone.
Capstone — annotate the module to pass the type contract
Loading exercise…
Tested in P30, typed here: the module is now robust. Next track — designing the errors it raises when something does go wrong.
Where next?
Go up a level