Support native dataclasses out of the box

[uriva]

I use the native dataclasses api, and I imagine that this will be the standard for python apps in the coming future, so I think fastapi should support them without requiring the use of pydantic.

Otherwise, a heavily nested dc will require changing a lot of code.

The common situation is this:

@dataclasses.dataclass(frozen=True)
class A:
  b: B

@dataclasses.dataclass(frozen=True)
class B:
   ...

Where I want to use A in my fastapi app, but I end up having to convert A to pydantic (via mix-in or by giving up dataclasses features).

Even if I do that, I might need to convert B as well, so this is quite a big change to introduce for an api that's supposed to affect just the networking side of things.

Side note: I'm using dataclasses_json to convert to json, so I have two decorators.

[dmontagu]

I use the native dataclasses api, and I imagine that this will be the standard for python apps in the coming future

I would agree that dataclasses will be used more and more regardless of pydantic usage, but I think there are a number of benefits to using BaseModel specifically on the API interface (e.g., support for camel case aliases), and I don't think the built-in dataclasses will be able to support everything you'd frequently want to be able to customize in a parsing context. (Though frequently it is enough.)

Typically, I would use dataclasses wherever I know the type will not be exposed via API, and BaseModel where I know it will.

or by giving up dataclasses features

For what it's worth, pydantic has a pydantic.dataclasses.dataclass decorator that should give you equivalent "features", and is supported by FastAPI.

---

That said, I would totally be in favor of adding better support for raw dataclasses by basically having FastAPI create a pydantic dataclass as an auxiliary type, use that for parsing, and then dump the parsed results into the original non-pydantic dataclass. (Assuming someone else was willing to write the PR 😁.)

Given FastAPI already supports the use of pydantic dataclasses, I think it wouldn't be too hard to implement this. It would also have the benefit of not adding parsing overhead when instantiating the dataclass in your own code (it is possible to avoid the parsing overhead with BaseModel.construct, but there is no way to instantiate a pydantic dataclass without parsing). That said, it would have the downside of making it impossible to run the parsing without the use of the framework, but I think that's less frequently useful anyway.

I'm curious what @tiangolo thinks about this.

---

Related, it might make sense to add raw-dataclass support for pydantic.tools.parse_obj_as, which would also probably make it easier to integrate this feature into FastAPI.

[ptone]

One example of a cool library that I was hoping to use with fastapi, that does not seem to work with the pydantic dataclass adapter: https://github.com/nabla-c0d3/fireclass (Document and BaseModel seem to interfere)

AttributeError: 'Foo' object has no attribute '_id'

[tiangolo]

@uriva one simple option is that, if you want your app to only affect just the networking side of things, without documentation, serialization, validation, you can just use the request directly and instantiate your dataclasses with the contents of the request.

But again, that would mean giving up validation, documentation, etc.

The way all that is supported in FastAPI is via Pydantic. Pydantic is what does the validation and serialization. And JSON Schemas are generated by Pydantic (then incorporated into OpenAPI).

I guess the first step to support plain dataclasses would be to have something to convert from a plain dataclass to a Pydantic model automatically. I think that would probably require a considerable effort, and I think that would belong in Pydantic or a third-party package. Not FastAPI itself.

@ptone have you tried inheriting from both classes? The BaseModel and that one? It might work...

[github-actions[bot]]

Assuming the original issue was solved, it will be automatically closed now. But feel free to add more comments or create new issues.