What Are Typed Data Containers?

Python offers several ways to avoid this bug, each adding more safety than the last:

Notice the pattern: each row gains something the previous one lacks:

• dict → NamedTuple: Gain fixed fields, lose flexibility.
• NamedTuple → dataclass: Gain mutability and defaults.
• dataclass → Pydantic: Gain type validation, add a dependency.

In this course, you’ll try each tool yourself and see how it catches the mistakes that dictionaries miss.

Creating a Dictionary

A dictionary maps string keys to values. It’s the most common way to represent a record in Python, but it has no fixed structure. You can add, remove, or misspell any key at any time.

Creating one takes a single pair of curly braces:

Silent Failures

A typo in the key name causes a KeyError at runtime:

The error tells you what went wrong but not where. When dictionaries pass through multiple functions, finding the source of a typo can take significant debugging time:

Using .get() makes it worse by returning None silently:

Quiz

Type Confusion

Missing keys aren’t the only risk. Without a schema, dictionaries also accept the wrong type for any field.

Let’s see what happens when age is stored as a string instead of an integer:

Creating a NamedTuple

NamedTuple is a lightweight way to define a fixed structure with named fields and type hints, like a dictionary with a schema.

Instead of string keys, you declare a NamedTuple class with fixed fields. Every object created from it must provide values for those exact fields:

Once created, you can access fields with dot notation instead of string keys like customer["name"]. This allows your IDE to autocomplete the field names and catch typos immediately:

Quiz

Catching Typos at Runtime

In the dictionary pipeline, load_customer returned {"emial": row[2]} and the typo traveled through validate_customer before crashing in send_email. With NamedTuple, the same typo fails at the source:

Quiz

Exercise: Fix a Buggy Pipeline

Immutability Prevents Accidental Changes

Dictionaries let you change any value at any time, which means fields can be overwritten by accident. NamedTuples are immutable, so once created, their values cannot be changed:

Quiz

Default Values

NamedTuple supports default values for simple types like bool and str:

However, mutable defaults like lists are shared across all instances, which can cause unexpected behavior:

This diagram shows how the single default list is shared before and after the append:

---
config:
  theme: dark
  layout: dagre
  look: neo
---
flowchart TD
    subgraph After c1.tags.append
        c1b[c1.tags] --> list2["['premium']"]
        c2b[c2.tags] --> list2
    end

    subgraph Before append
        c1a[c1.tags] --> list1["[ ]"]
        c2a[c2.tags] --> list1
    end

Quiz

Limitations: No Runtime Type Validation

Type hints in NamedTuple are not enforced at runtime. You can still pass in wrong types:

Quiz

Exercise: Fix a Type Bug

Creating a dataclass

A dataclass is a class decorator that automatically generates __init__, __repr__, and other methods from field definitions. It provides the same fixed fields and IDE support as NamedTuple, plus:

• Mutable fields: Change values after creation, unlike NamedTuple
• Default values: Fields can have defaults, including empty lists and dicts
• Post-init logic: Run custom code right after an object is created

Creating a dataclass looks similar to NamedTuple, but you use the @dataclass decorator instead of inheriting:

Quiz

Exercise: Build a Product Record

Mutability Allows Updates

Dataclass trades NamedTuple’s immutability protection for flexibility. You can modify fields after creation:

To prevent accidentally adding new attributes, you can use @dataclass(slots=True), which creates a fixed set of attributes that cannot be changed:

Quiz

Mutable Defaults with default_factory

Remember the shared list problem from NamedTuple? Dataclass prevents this by rejecting mutable defaults entirely:

Dataclass offers field(default_factory=...) as the solution. The factory function runs at instance creation, so each object gets its own list:

To see why this works, compare what happens at creation versus after appending:

---
config:
  theme: dark
  layout: dagre
  look: neo
---
flowchart TD
    subgraph After order1.items.append
        o1b[order1.items] --> list1b["['apple']"]
        o2b[order2.items] --> list2b["[ ]"]
    end

    subgraph At creation
        o1a[order1.items] --> list1a["[ ]"]
        o2a[order2.items] --> list2a["[ ]"]
    end

Quiz

Exercise: Build a Shopping Cart

Post-Init Validation with __post_init__

Dataclass accepts any value that matches the type signature, so invalid data like empty names or negative ages passes through without warning:

To catch these issues early, dataclass provides a special method called __post_init__ that runs automatically after __init__ finishes. You can add validation logic here to reject bad values at creation time:

Quiz

Limitations: Manual Validation Only

__post_init__ requires you to write every validation rule yourself. If you forget to check a field, bad data can still slip through:

Limitations: Nested Validation

Most real data is nested: customers have addresses, orders have items. With dataclass, error messages don’t tell you where in the structure the problem occurred:

Quiz

Getting Started

So far, every container has treated type hints as documentation only. Pydantic is a third-party validation library that changes this. It checks types at runtime and raises clear errors when values don’t match.

To install Pydantic, run:

pip install pydantic

This course uses Pydantic 2.12.

Let’s verify the installation:

Creating a Pydantic Model

Creating a Pydantic model looks similar to dataclass and NamedTuple. To create a Pydantic model, inherit from BaseModel and declare your fields:

Runtime Validation

Remember how dataclass accepted name=123 without complaint? Pydantic catches this automatically:

Quiz

Exercise: Validate Signup Data

Type Coercion

Unlike dataclass which stores whatever you pass, Pydantic automatically converts compatible types:

Quiz

Constraint Validation

Beyond types, you often need business rules: age must be positive, names can’t be empty, customer IDs must follow a pattern.

In dataclass, you define fields in one place and validate them in __post_init__. But raise stops at the first error, so you only learn about one problem at a time:

Pydantic puts constraints directly in Field(), keeping rules next to the data they validate:

Here are the most common Field() constraints:

See the full list of Field parameters in the Pydantic docs.

Quiz

Exercise: Validate a Job Posting

Nested Validation

In the dataclass example, the error only said “Invalid zip: 9ABC1” with no way to trace it back to address.zip_code. Pydantic fixes this by reporting the full path to each error:

Quiz

Key Takeaways

Here’s what each tool provides:

• dict: Quick to create, but silent failures from typos, missing keys, and wrong types make bugs hard to trace.
• NamedTuple: Catches typos at creation and provides immutability, but does not enforce types at runtime and shares mutable defaults.
• dataclass: Rejects mutable defaults with default_factory and supports validation via __post_init__, but errors are reported one at a time with no nesting path.
• Pydantic: Enforces types at runtime, catches all validation errors at once, and reports the full path through nested structures like address.zip_code.