Support pydantic dataclass models

[GlenNicholls]

I am using pydantic.dataclasses.dataclass because I need the __post_init__ dunder. However, I noticed that automodule does not generate the pydantic model documentation for these data classes. Looking at pydantic's docs, I can access the model using __pydantic_model__, but I'm not sure how to get this to happen automatically with automodule?

[mansenfranzen]

@GlenNicholls Thanks for raising this feature request here! I agree it would be really helpful to support pydantic.dataclasses.dataclass. At first glance, this should be possible without too much effort but I will need to take a closer look at it. I will come back to you soonish.

[mansenfranzen]

While having a closer look at it, I came across two usage questions:

• Do you need a custom signature prefix for dataclasses to distinguish them from pydantic models/settings?
• Do you need separate configuration properties for dataclasses to behave differently from pydantic models or do the same configuration settings apply as for pydantic models?

In my opinion, dataclasses should be distinguishable from models/settings via a custom prefix. However, their documentation/rendering behavior should be the same

[GlenNicholls]

Do you need a custom signature prefix for dataclasses to distinguish them from pydantic models/settings?

No, the reason I'm using pydantic dataclass is because I need validation for a config file but also to modify some behavior based on data relationships with __post_init_post_parse__/__post_init__. I don't really care if those docstrings are present as it's taking care of transformations that don't really concern users. The docstring is in the code for devs because it matters to them, but It's not relevant otherwise.

Do you need separate configuration properties for dataclasses to behave differently from pydantic models or do the same configuration settings apply as for pydantic models?

Nope. I'm sure someone will ask for that eventually, but I just want the dataclass model to get documented the same as a pydantic model. I'm happy with the defaults so those would be fine with me for dataclasses.

EDIT: regarding your second question, if there is something specific you're thinking of, it won't matter to me is what I'm getting at. I don't have a preference as autodoc_pydantic is miles ahead of anything I've tried so far, but if that changes, I'll open something more specific about what I need.

[mansenfranzen]

Okay thanks for your response. I guess I will support explicit configurations for dataclasses right away instead of using the same configuration settings as for models. As you've pointed out, this will become a requirement eventually by someone using dataclasses. Supporting it right from the beginning may prevent backwards incompatibility later on.

This will take me some time to accomplish and it will land in v1.8.0.

[nilsAnso]

Is there a reason, why this is removed? Would be a nice feature.

[mansenfranzen]

Thanks to @coretl, there is an initial PR to provide support for dataclasses (see #298).

I would like to disucss further details here instead of the PR to keep others in the loop who might have not noticed the PR.

@coretl I really like the simplicity of your PR by treating dataclasses as a pydantic models. However, dataclasses will not be rendered as dataclasses in the docs but will be shown as pydantic models (more concretely, the signature prefix is not correct, see here). I worry that this behavior is not expected by most users. Instead, dataclasses should probably be specified as a pydantic dataclass instead of a pydantic model. @GlenNicholls @nilsAnso @coretl What is your opinion?

Moreover, there seem to be subtle differences between pydantic base model and pydantic dataclasses (see here and here). I believe it it will be necessary to run all tests on dataclass based models that already exist for pydantic models. Otherwise, we might miss some edge cases here.

Last but not least, I assume that users might want to configure the docs behavior of dataclasses to be different from pydantic models. This would have rather large implications. Ideally, we could leave this out for now.

I'm looking forward to your thoughts.

[coretl]

I worry that this behavior is not expected by most users. Instead, dataclasses should probably be specified as a pydantic dataclass instead of a pydantic model. @GlenNicholls @nilsAnso @coretl What is your opinion?

I suspect you are correct here, I never considered this when making my PR. Unfortunately I don't have any more time to work on this PR, so I will convert it to draft and leave it there in case it is useful for someone else making a final solution.