Support for Python dataclasses in default JSON Encoder

[nikoder]

Python dataclasses, introduced in Python 3.7, are a convenient way to represent simple objects and they reflect trivially to dictionaries (and thus to JSON).

Unfortunately, Python's json.JSONEncoder, which DRF's one is built on, does not support serialising dataclasses.

Does it make sense to add generic support for dataclesses to the default rest_framework.utils.encoders.JSONEncoder?

Would you be open to a PR to add this feature?

A simple:

+import dataclasses

[...]

class JSONEncoder(json.JSONEncoder):
    [...]
    def default(self, obj):
        [...]
+        if dataclasses.is_dataclass(obj):
+            obj = dataclasses.asdict(obj)

seems to do the trick for my use case, though there might be plenty of complexities I'm not thinking of, as a DRF noob.

I see that currently:

REQUIRED_PYTHON = (3, 6)

so that speaks at least against my naive approach, even if the feature sounds good in general.

[auvipy]

drf is an extension of django, so we have to take how django is using dataclass right now

[auvipy]

I meant, is django using dataclass yet? I haven't seen any usage of it. for django REST framework, If you can come with a propper use case and a fix, we can ofcourse add suport for dataclass serialization in DRF.

[auvipy]

we are going to drop python 3.6 support very soon

[nikoder]

Oh, cool! And thanks for clarifying :) .

I'm not aware that Django is using dataclasses yet either.

Use Case

My use case is that I use dataclasses to represent record-like state all throughout my application and sometimes I would like to e.g. return such a record as part of a rest_framework.response.Response().

The Case For

Right now, I can return anything that rest_framework.utils.encoders.JSONEncoder supports. There are a few special cases already implemented for types which are not supported by Python's JSON encoder, but they do not include dataclasses.

I could use dicts instead, but dataclasses are much nicer, as they offer type hinting, validation and other conveniences over dictionaries. I can also explicitly convert from dataclass to dict at the time of building the Response, but this is less convenient and I have to change the way the response is built every time I decide to change the representation of some bit of state to a dataclass or vice versa.

Necessity

It's not a huge pain point by any means: Thanks to DRF's extensibility, I can easily change the default Renderer to be a customised rest_framework.renderers.JSONRenderer which uses a customised rest_framework.utils.encoders.JSONEncoder, which adds the two line special case (posted in the original proposal above) for dataclasses to its existing set of special cases. I just thought it might be a nice feature to have in the default behaviour :) .

The Case Against

Thinking about further points which speak against my proposal, the following comes to mind:

• Why doesn't the underling Python JSON encoder support dataclasses out of the box? Is this just an oversight on the Python side, or are there reasons one might not want to be able to serialise dataclasses by default?
• I'm not sure if the default JSONEncoder is used for other purposes, besides building Responses. Having this added functionality in any potential other scenarios might add weight for or against this proposal, of course, or make it a downright non-starter.
• Based on the documentation of dataclasses.asdict(), the implementation is recursive and uses copy.deepcopy() on any non-dataclass objects encountered, which means it may be significantly more expensive than the default behaviour in some cases. A shallow alternative to asdict() would solve this, but it doesn't seem to come out of the box in Python.
• Maybe Django will adopt dataclasses in a clever way? They have a few things in common with Django Models already (defining fields with various associated metadata), but type hinting in Django is still sparse. I have no idea what plans might exist, but there seems to be potential there and it might conflict with this proposal when any such plans come to fruition.

[auvipy]

Django don't see incorporating typing in existing codes yet. but if you can do some tweaks in DRF, which will make life of end developers without making big breaking changes to DRF, contributions are welcome.

[nikoder]

Thanks @auvipy ! And sorry for my very long communication latency...

I've taken a crack at implementing the relevant changes in this branch: nikoder:django-rest-framework:nikoder_add_support_for_simple_dataclasses_in_default_json_encoder .

The essence is the 3 line change in d0983e9 . The rest is a test and my naive stab at bumping the minimum Python version to 3.7.

I've successfully run tests against Python 3.7 and 3.11. As mentioned, dataclasses are a 3.7 feature, so my change, as implemented, would depend on bumping the minimum Python version to 3.7.

If you are still interested in the change, would you like me to do any of:

1. Open a PR as is (including the 3.7 changes)
2. Open a PR without the 3.7 changes, with the expectation of handling the upgrade separately and this PR staying open until that has happened
3. Change the implementation to try to maintain compatibility with 3.6
4. Something else/none of the above?

Either way, if we move this change forward, I imagine there will be further steps needed, on top of to my naive noob attempt at making a contribution :) .

[auvipy]

I think we can atleast experiment with dataclass support in DRF :)

[nikoder]

Cool, thanks auvypy :) .

Sorry, just to clarify: Does that mean that you'd like me to open a PR for my branch as is, or did you have some specific experiments in mind first?

[auvipy]

I would love to see you come with a draft PR. if you feel that after some initial experiment you can't continue, we can pass it to others including me :)