djangorestframework-dataclasses

Warnings

• breaking Type annotations in `djangorestframework-dataclasses` versions 1.3.0 and newer require `mypy` 1.0 or higher for correct validation. Older `mypy` versions may produce incorrect results or errors.
  Fix: Upgrade `mypy` to version 1.0 or newer in your development environment or CI/CD pipelines.
• breaking In versions 0.9.0 and later, dataclass fields with a default value or `default_factory` are automatically marked as optional (`required=False`) in the serializer. Marking a field with `typing.Optional` now only makes it nullable, not optional. If a field previously relied solely on `typing.Optional` to be non-required, it will now be considered required if it doesn't have a default value.
  Fix: Ensure fields intended to be optional have a default value (e.g., `field: str = ''` or `field: Optional[str] = None`) or `default_factory`. For explicit control, use `extra_kwargs={'field_name': {'required': False}}` in the `Meta` class.
• gotcha As of v1.1.0, `djangorestframework-dataclasses` supports the new `X | None` union syntax (PEP 604) for specifying optional fields in Python 3.10+. This is the preferred modern way to declare optional fields.
  Fix: When targeting Python 3.10 and newer, use `FieldType | None` instead of `typing.Optional[FieldType]` for optional fields in your dataclass definitions.
• gotcha The `validated_data` representation no longer contains the `rest_framework.fields.empty` sentinel value for unsupplied fields since v0.8. This change reverted a breaking behavior introduced in v0.7. Code relying on the presence of `empty` for unsupplied fields will need adjustment.
  Fix: Modify code to check for the absence of a key in `validated_data` using `if 'key' not in validated_data:` instead of checking for `value is rest_framework.fields.empty`.
• gotcha With v1.3.0, values for fields of non-list/dict composite types (e.g., `frozenset`, `OrderedDict`) are now created as their specific composite type, rather than always `list` or `dict`. This provides more accurate type handling but might affect existing code if it implicitly relied on the previous generic behavior.
  Fix: Review serialization/deserialization logic for custom or less common composite types. If specific serialization behavior is needed, use the `serializer_field_mapping` dictionary in the serializer's `Meta` class to override the field for those types.

Install

• pip install djangorestframework-dataclasses Install stable version

Imports

• DataclassSerializer

  from rest_framework_dataclasses.serializers import DataclassSerializer

Quickstart

This quickstart demonstrates how to define a dataclass, create a `DataclassSerializer` for it, and then use the serializer to convert a dataclass instance into a dictionary (serialization) and to create a dataclass instance from a dictionary (deserialization), including handling default values.

from dataclasses import dataclass
import datetime
from typing import Optional

from rest_framework import fields, serializers
from rest_framework_dataclasses.serializers import DataclassSerializer

@dataclass
class UserProfile:
    username: str
    email: str
    is_active: bool = True
    date_joined: Optional[datetime.datetime] = None

class UserProfileSerializer(DataclassSerializer):
    class Meta:
        dataclass = UserProfile
        fields = '__all__'

# Example Usage:
# Serialization
user_instance = UserProfile(
    username='testuser',
    email='test@example.com',
    date_joined=datetime.datetime.now(datetime.timezone.utc)
)
serializer = UserProfileSerializer(user_instance)
print("Serialized data:", serializer.data)

# Deserialization
data = {
    'username': 'newuser',
    'email': 'new@example.com'
}
deserializer = UserProfileSerializer(data=data)
deserializer.is_valid(raise_exception=True)
new_user_profile = deserializer.validated_data
print("Deserialized object:", new_user_profile)
print("Deserialized username:", new_user_profile.username)
print("Deserialized is_active (with default):", new_user_profile.is_active)