Django-rest-framework: [Feature request] DataclassSerializer for new Python's Dataclasses

Created on 12 Jun 2018  路  11Comments  路  Source: encode/django-rest-framework

Data classes is the new feature of Python 3.7 https://www.python.org/dev/peps/pep-0557/
It seems worth to add DataclassSerializer to DRF, that would work similar to ModelSerializer.

Most helpful comment

I have just uploaded the djangorestframework-dataclasses package on PyPi, which implements a serializer for dataclasses (based on the ModelSerializer). I haven't completely finished it yet and still need to write tests, but it should be quite useful already.

Suggestions and pull requests are welcome on the GitHub project!

All 11 comments

Seems like a good idea.

It seems worth to add DataclassSerializer to DRF, that would work similar to ModelSerializer.

Thanks.

@dataclass saves you from having to write some amount of boilerplate methods. Given that we can't drop support for < 3.7 yet, I'd suggest that any of the methods we do want to support should be included on out base class explicitly. (Eg. I think we could probably consider pull requests that included __eq__ and __ne__ implementations.

Perhaps once we're only supporting >=3.7 we'd then be able to drop those implementations in favor of @dataclass

However I suspect it's more likely that the intent of opening this issue is "can we use declared types", rather than serializer fields. In which case it's a reasonable intent, but not flexible enough for actual use cases (max_length, relationships, unique, etc.)

I think it's worth having a generic dataclass serializer, which behavior can be refined then. Dataclasses are superior at defining the schema. Serializers are very good and useful at structures transformation and adaptation. So I think it's a good idea to have a nice and convenient integration of these tools.

Some code I can imagine:

@dataclass
class Person:
  name: str
  age: int

class PersonSerializer(drf.DataclassSerializer(Person)):
  # here we have a possibility to override some pre-defined behavior
  name = CharField(...)

# Another way of customization
PersonSerializer = drf.DataclassSerializer(Person)
PersonSerializer.name.source = 'another.source'

I鈥檇 be very happy to see someone build this. There鈥檚 absolutely no reason this can鈥檛 start off as a third party package.

Dataclasses was backported as a package to Python 3.6 https://pypi.org/project/dataclasses/

can we talk here about how would this 3rd party package look like? is some other place more appropriate?

See the Third Party Packages guide.

Actual implementation details, probably on the Mailing List.

I have just uploaded the djangorestframework-dataclasses package on PyPi, which implements a serializer for dataclasses (based on the ModelSerializer). I haven't completely finished it yet and still need to write tests, but it should be quite useful already.

Suggestions and pull requests are welcome on the GitHub project!

I also found this one https://github.com/shosca/django-rest-dataclasses

Yeah, that's an unfortunate case of parallel development (I developed most of my package within another project in late spring, when this wasn't released yet; but didn't have time to split it out and package it nicely until last week).

However, from a quick look at the code, my implementation seems to be more flexible (support for optional fields, arbitrarily nested iterables and mappings, PEP 563 type hints, links to Django models, anonymous usage). This one supports depth though, which I still need to do.

I think a fundamental rethinking of serializers would be a big boost to this project. It'd be awesome to:
1) have declared types in serializers, where the type annotation can do automatic validation for simple use cases.
2) maintain integration with Django's ORM for foreign key relations and automatically generating serializer fields from a model class; maybe this takes the form of a manage.py command that automatically generates a typed serializer class from the model. Model serializers and viewsets are amazing for productivity when churning out CRUD features.
3) simplify things: do away with any persistence methods on the serializer class (create, destroy, update). These should probably be handled on the view/controller anyway -- though I get that they were originally a REST counterpart to Django's forms, which do have a save() method.

I'm not sure where dataclasses fit into this. As Tom said, they don't seem flexible enough. I think pydantic offers a more realistic approach.

Was this page helpful?
0 / 5 - 0 ratings