Data Classes & Pydantic

This lesson on Data Classes & Pydantic is hands-on and example-driven. You will select, implement, and customize structured data models across Python's dataclasses, attrs, and Pydantic libraries. You will configure mutable default factories, customize equality comparisons, and enforce strict runtime validation based on your system requirements.

What You'll Be Able To Do

• Construct domain data models using standard library dataclasses with appropriate type hints and default factories.
• Eliminate shared mutable state bugs by configuring default_factory for list and dictionary attributes.
• Customize object equality logic in dataclasses by selectively excluding non-identifying attributes.
• Implement pre-comparison transformations such as case-insensitive matching using the attrs library.
• Enforce runtime validation constraints on data models using Pydantic BaseModel and specialized field types.

Detailed Concept Walkthrough

1. Standard Data Classes and Default Factories

Python's built-in dataclasses decorator automatically generates standard boilerplate methods based on class-level type annotations. It provides a lightweight, dependency-free mechanism for encapsulating structured state.

• Mechanism: The @dataclass decorator inspects class annotations at definition time and generates __init__, __repr__, and __eq__ methods automatically.
• Under the Hood: Mutable default arguments assigned directly in class definitions are shared across all instances; dataclasses.field(default_factory=...) ensures a new instance is created dynamically during instantiation.
• Best Practice: Always represent monetary values as integer quantities representing the smallest denomination (such as cents) to avoid floating-point representation bugs.

from dataclasses import dataclass, field

@dataclass
class Product:
    sku: str
    unit_price_cents: int  # Store money in cents to avoid float inaccuracy

@dataclass
class Order:
    order_id: int
    items: list[Product] = field(default_factory=list)  # Safe mutable default

order = Order(order_id=101)
order.items.append(Product(sku="PROD-A", unit_price_cents=1999))
print(order)

Key Takeaway: Use dataclasses for standard in-memory domain models, and always isolate mutable defaults with default_factory.

2. Customizing Equality Comparisons in Dataclasses

By default, dataclass equality checks compare all declared fields across both instances. You can narrow comparison semantics by excluding fields that should not affect object identity.

• Mechanism: Setting compare=False inside dataclasses.field() excludes that specific attribute when the generated __eq__ method runs.
• Under the Hood: The synthesized __eq__ builds and evaluates an internal tuple of attributes; fields with compare=False are omitted from this comparison tuple.
• Nuance: Fields excluded from comparison still participate in __init__ and __repr__ unless explicitly disabled using init=False or repr=False.

from dataclasses import dataclass, field

@dataclass
class Product:
    sku: str
    # unit_price excluded from object equality evaluations
    unit_price: int = field(compare=False)

p1 = Product(sku="BOOK-42", unit_price=1500)
p2 = Product(sku="BOOK-42", unit_price=2000)

# Evaluates to True because unit_price is ignored in __eq__
print(p1 == p2)

Key Takeaway: Set compare=False in field definitions when two objects should be considered identical despite differences in volatile metadata.

3. Advanced Value Transformations with Attrs

The attrs library extends beyond binary field exclusion by allowing custom transformation functions during comparison operations. This enables normalized equality checks like case-insensitive string matching.

• Mechanism: The @attr.define decorator provides rich configuration options per field, including pre-comparison value processing via field arguments.
• Under the Hood: During an equality evaluation, attrs routes field values through designated transformation callables before evaluating equality.
• Syntax Rule: While dataclasses only permit boolean inclusion via compare, attrs allows functional comparators like eq=str.lower.

import attr

@attr.define
class Product:
    # Normalizes strings to lowercase prior to equality comparison
    name: str = attr.field(eq=str.lower)
    unit_price: int = attr.field(eq=False)  # Completely excluded from comparison

p1 = Product(name="Widget", unit_price=100)
p2 = Product(name="WIDGET", unit_price=250)

# Evaluates to True: case-insensitive name match and price ignored
print(p1 == p2)

Key Takeaway: Adopt attrs when object equality depends on value transformations rather than strict literal value matching.

4. Runtime Data Validation with Pydantic

Pydantic enforces strict runtime validation and parsing by subclassing BaseModel. It guarantees that incoming data matches schema types and domain boundary constraints.

• Mechanism: Models inherit from pydantic.BaseModel rather than using decorators; inputs are parsed and coerced into specified types upon instantiation.
• Under the Hood: If input values fail type parsing or boundary assertions, Pydantic immediately aborts instantiation and raises a ValidationError.
• Best Practice: Combine constrained types like PositiveInt and Field bounds (e.g., ge=0.0, le=1.0) to validate business rules at boundary layers.

from pydantic import BaseModel, Field, PositiveInt, ValidationError

class Product(BaseModel):
    sku: str
    price_cents: PositiveInt
    discount_pct: float = Field(ge=0.0, le=1.0)  # Bound between 0.0 and 1.0

try:
    # Fails validation due to negative price and invalid discount range
    bad_product = Product(sku="INVALID", price_cents=-50, discount_pct=1.5)
except ValidationError as err:
    print(err)

Key Takeaway: Use Pydantic at application boundaries where external input must be validated and coerced against strict schemas.

Topics Covered in Data Classes & Pydantic

1. Structured Data Frameworks Overview (0:00 - 0:55) — The instructor outlines the strengths and limitations of standard dataclasses, Pydantic, and attrs.
2. Standard Dataclass Implementation (1:23 - 3:59) — The instructor builds Product and Order models while explaining type hints, mutable defaults, and integer currency representation.
3. Customizing Dataclass Comparisons (3:59 - 5:10) — The instructor demonstrates how setting compare=False inside field definitions alters object equality behavior.
4. Advanced Comparisons with Attrs (5:10 - 6:14) — The instructor uses the attrs library to apply custom transformation functions before executing equality checks.
5. Modeling with Pydantic BaseModel (6:14 - 7:34) — The instructor implements models using Pydantic subclassing and evaluates its built-in comparison constraints.
6. Runtime Validation with Pydantic (7:34 - 8:46) — The instructor applies specialized types and Field constraints to enforce runtime validation and trigger ValidationError handling.

Python Cheat Sheet

• @dataclass — Generates init, repr, and eq from type hints

  from dataclasses import dataclass
  @dataclass
  class Item:
      sku: str
  

• field(default_factory=...) — Provides a fresh mutable default value per instance

  from dataclasses import dataclass, field
  @dataclass
  class Cart:
      items: list = field(default_factory=list)
  

• field(compare=False) — Excludes an attribute from generated eq comparisons

  from dataclasses import dataclass, field
  @dataclass
  class Item:
      id: int
      price: int = field(compare=False)
  

• @attr.define — Declares an attrs class with advanced comparison capabilities

  import attr
  @attr.define
  class User:
      email: str = attr.field(eq=str.lower)
  

• class Model(BaseModel): — Defines a Pydantic model with runtime type validation

  from pydantic import BaseModel
  class User(BaseModel):
      id: int
      username: str
  

• Field(ge=..., le=...) — Sets numeric and range validation constraints on fields

  from pydantic import BaseModel, Field
  class Rate(BaseModel):
      pct: float = Field(ge=0.0, le=100.0)
  

Comparison Table

Common Pitfalls

• Mistake: Assigning a mutable default directly to a dataclass attribute. Avoid: Use field(default_factory=list) or field(default_factory=dict) to prevent shared instance state.
• Mistake: Using floating-point values to represent currency in models. Avoid: Store currency as integer units like cents to eliminate rounding and precision errors.
• Mistake: Expecting dataclasses to validate input types at runtime. Avoid: Use Pydantic BaseModel whenever runtime type coercion or boundary validation is necessary.
• Mistake: Choosing Pydantic when advanced comparison transforms are required. Avoid: Use attrs when object equality depends on transformations like case-insensitive normalization.

FAQs

• Why should I use integers instead of floats for currency fields? Floating-point numbers produce binary rounding inaccuracies during arithmetic. Using integer counts of the smallest unit (such as cents) guarantees exact precision.
• When should I use dataclasses instead of Pydantic? Use standard dataclasses for internal, trusted data structures that need minimal performance overhead and zero third-party dependencies.
• How does comparison customization differ between dataclasses and attrs? Dataclasses only allow binary inclusion or exclusion of fields using compare=False, whereas attrs allows transformation callables like str.lower during comparison.
• What happens when invalid data is passed to a Pydantic model? Pydantic raises a ValidationError that identifies each invalid field, the received value, and the specific constraint violated.