Typorithm learning path
Pydantic: reliable data contracts
Models, required versus nullable fields, constraints, strict channels, validators, nested errors, aliases, discriminated unions, TypeAdapter, safe serialization, JSON Schema, validated updates, generics, settings and a scoped-report capstone. Six substantive sections per topic, short warm-ups and typing, a working exercise baseline, two hints and one small policy change at a time. Verified with Python 3.13 and Pydantic 2.14.3 and pydantic-settings 2.16.2. Reading and reasoning progress work in the app; Python execution uses the downloadable isolated computer lab with owned data and in-process clients.
Study with a practical destination
Use the linked lessons in order, complete the lab and explain the decisions without the reference. Select the path and depth that match your role.
Pydantic: explicit data boundaries
Before starting: Python foundations and basic HTTP; study Pydantic contracts before the FastAPI track. Real execution uses the isolated pinned computer lab.
Build and explain: Validate, normalize and safely project bounded data contracts with current Pydantic behavior.
- 1. Models validate a boundary, not a Python annotation
- 2. Required, nullable and omitted are three different decisions
- 3. Annotated constraints belong to the value they constrain
- 4. Strict Python input and strict JSON are different channels
- 5. Field validators: normalize before, enforce meaning after
- 6. Model validators enforce relationships between fields
- 7. Nested errors need a path, not a copied request
- 8. Aliases accept legacy names without widening writable input
- 9. Discriminated unions make variant selection explicit
- 10. TypeAdapter validates a batch without a wrapper model
- 11. Serialize the public contract, not every private field
- 12. Validation schema and serialization schema describe different directions
- 13. Validate external patches before creating the next model
- 14. Generic envelopes must retain their item contract
- 15. Settings have a source, a precedence and a validation policy
- 16. Capstone: a checked, country-scoped report contract
Review evidence: Use a short warm-up, reconstruct one focused decision, then change one policy in a working baseline before opening the solution. Run positive and negative cases; reading progress does not claim professional certification or production readiness.
Your learning path
0 of 16 lessons completed
Saved on this device
Module 1 · 1 lessons
Models validate a boundary, not a Python annotation
Turn an untrusted mapping into a checked model and inspect the normalized output.
Module 2 · 1 lessons
Required, nullable and omitted are three different decisions
Preserve the difference between a missing field and an explicitly supplied null.
Module 3 · 1 lessons
Annotated constraints belong to the value they constrain
Constrain collection size and individual items without confusing the two.
Module 4 · 1 lessons
Strict Python input and strict JSON are different channels
Use strict validation deliberately and test both input representations.
Module 5 · 1 lessons
Field validators: normalize before, enforce meaning after
Separate a permitted normalization from a domain check and always return the checked value.
Module 6 · 1 lessons
Model validators enforce relationships between fields
Check a range after its individual fields have passed their own contracts.
Module 7 · 1 lessons
Nested errors need a path, not a copied request
Keep collection indexes and parent fields when explaining a validation failure.
Module 8 · 1 lessons
Aliases accept legacy names without widening writable input
Separate validation names, internal names and response names, and reject unexpected siblings.
Module 9 · 1 lessons
Discriminated unions make variant selection explicit
Use a declared tag to choose a model shape and retain useful failures for unsupported variants.
Module 10 · 1 lessons
TypeAdapter validates a batch without a wrapper model
Reuse an adapter for an existing type and distinguish item validity from duplicate-work policy.
Module 11 · 1 lessons
Serialize the public contract, not every private field
Use an explicit output type and understand the limits of secret masking.
Module 12 · 1 lessons
Validation schema and serialization schema describe different directions
Read generated schemas alongside actual validation and computed output.
Module 13 · 1 lessons
Validate external patches before creating the next model
Treat model_copy updates as trusted operations rather than a new validation boundary.
Module 14 · 1 lessons
Generic envelopes must retain their item contract
Validate a Page of roles as Page[Role], not as an untyped collection wrapper.
Module 15 · 1 lessons
Settings have a source, a precedence and a validation policy
Load only a dedicated synthetic environment prefix and disable incidental dotenv files.
Module 16 · 1 lessons
Capstone: a checked, country-scoped report contract
Combine nested validation, duplicate rejection and derived counts without inventing market totals.