Objective & prerequisites
Use an immutable value object to enforce a small, explicit data contract. Before starting: basic Python functions, dictionaries, loops, JSON and terminal use. Complete the earlier Git/API/testing workshops if these are unfamiliar. Download and extract the kit into a new practice folder, then open a terminal in the software-kit folder. Python 3.10+ is required; the reference uses only the standard library. Work with the supplied fictional data. These free companion lessons do not change protected course access or award progress or certificates.
python3 --version
python3 -m unittest discover -s tests -vUnderstand the concept
A class defines a type; an instance holds the values for one record. A method operates on that instance through self. The supplied Order dataclass groups order_id, channel and amount_cents. Its __post_init__ method checks values after construction. Type annotations help readers and tools but do not perform these runtime checks. frozen=True prevents ordinary reassignment after construction; it is a coding boundary, not a security boundary or proof of deep immutability. Keeping integer cents avoids binary floating-point surprises for this exercise. A valid zero is distinct from a missing value, and bool must be rejected explicitly because Python otherwise treats it as an integer subtype.
Worked example
Order("F01", "web", 12000) represents EUR 120.00 in fictional source data. Creating an order with True, a negative amount, an unknown channel or an empty ID raises ValueError. The upper limit is a declared teaching bound, not a universal financial rule. The frozen object has only immutable string and integer fields. An object with a mutable list field would require additional reasoning even if the dataclass were frozen.
from dch_orders import Order
order = Order("F01", "web", 12000)
assert order.amount_cents == 12000Try it yourself
Create one valid zero-value order. Predict and then test True, -1 and "12000" as amounts. In a local copy, add an optional currency field with only EUR allowed, and update every constructor and test that depends on the schema. Explain why silently converting a string or boolean would obscure the source contract. Write your expected outcome before running your implementation. Keep the supplied solution unchanged so that you can compare your own reasoning with it.
Worked solution
Zero remains valid; True, -1 and the string are rejected. Check type(value) is int before numerical bounds. A new currency field must be validated and documented at both JSON and object boundaries; otherwise the CLI and service may disagree. Compare your implementation with dch_orders/__init__.py and tests/test_orders.py. Existing tests deliberately use invalid construction to challenge the contract.
Knowledge check
Does writing amount_cents: int prevent callers from passing True?
Check and explain
No. An annotation does not enforce runtime types, and isinstance(True, int) is true. This contract deliberately checks exact integer type.
Evidence & common mistakes
Record the exact command, Python version, observed output and one rejected input. Explain what each check establishes and what it leaves untested. Do not remove validation merely to obtain a passing result. A local passing suite is evidence for these fixtures, not proof of production readiness. Credit the teaching reference and distinguish your own changes. The kit includes an exercise worksheet, a separate worked-solutions document, an API contract, expected results and a capstone rubric.
Authoritative reference
— official reference for the underlying interface. Lesson prose and fictional order examples are original. The teaching HTTP service is loopback-only, stateless and not suitable for production or uploading as a running Aruba service. No cloud account, paid API or registration is required.
Try the activity before reading its reference. Keep your sources, commands and assumptions with your work. Companion activities are unsaved self-practice and do not award a certificate or change lesson progress.