Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Appearance settings
Discussion options

Hi,

i'm using the that project for quite some time to generate openapi clients and frankly, it is by far the most usable library in that area!
However, i was wondering why pydantic is not used for models/dtos as well? Maybe there has been a discussion on this topic that i have missed, but since pydantic is anyway used internally (e.g. for parsing the openapi spec) why not just use it for DTOs as well? Especially now with pydantic v2, advantages like better support for type-hints, performance, convenience are numerous. Even more, there are projects like datamodel-code-generator around that might become handy in that regard as well..?

Is there any reason why to favor attrs over pydantic or was pydantic back then just not sufficiently mature enough? Pydantic was only at 1.4, back when the first release of that project was published to pypi..

Having a modern openapi client gen is i guess curcial for any ecosystem and this project is imho - to point it out once again - by far the best there is out there, when it comes to type-hints, generated code, support for pyproject.toml, http-client, asyncio etc....
Since the pydantic/fastapi "stack" got lots of attention recently, i was wondering whether this project could potentially go into similar directions in the future - and of course i'd be happy to contribute myself to such endeavors..

cheers

You must be logged in to vote

Replies: 1 comment · 2 replies

Comment options

I don't really remember why we didn't use Pydantic way back when. I think we started with only @dataclass to avoid extra dependencies in generated code, but then it didn't meet all our needs so we went to attrs because it was the most similar. I also didn't like the way they did required vs nullable, but that's been fixed with v2.

Having a version of the templates which uses Pydantic for models instead of attrs could definitely be useful, maybe with a CLI flag like --models pydantic (which defaults to attrs for backwards compatibility). Ideally, we'd make the way serialization and deserialization happens from the API modules work the same way so we don't have to have duplicate versions of those templates.

I could see a world where you can independently select the model style (pydantic, attrs, and maybe even @dataclass) and the HTTP library (as #795 is requesting). Like #795, there's a lot of testing code that will have to be put into place so that every change can be validated against both types of models, though.

You must be logged in to vote
2 replies
@dbanty
Comment options

The main downside to this feature is that it will cause future code contributions to be more difficult, as they'll have to support multiple types of models.

@JoeGaffney
Comment options

Hey, wondering it this happened. I imagine at this point people using would most probably be using Pydantic or at least benefit from the choice.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
3 participants
Morty Proxy This is a proxified and sanitized view of the page, visit original site.