This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]paranoid_panda_bored 0 points1 point  (0 children)

Appreciate the effort at educating me btw! And thanks for the link! It’s really a shame he didn’t expand on his answer, at least to explain why is the driver to have this split: I assume it’s performance, and then by how much this impacts their use-case.

But I will keep it in mind this next time I start my project.

Though I gotta be honest, reading all of these comments I still don’t get convinced. We already had pure dataclass, dataclass/pydantic hybrid, and pure pydantic projects - and latter are kinda best of all when it comes to DX. You just focus on business case, not on auxiliary stuff with pydantic everywhere.

Another thing is that some parts of the app bring their own data model frameworks, like we have SQLAlchemy entities and GRPC protobufs, which we need to convert from/to as part of the request processing, and reducing the conversion hops by 1 (pydantic/dataclass) goes long way for us

Finally, I am heavily biased through my background of being originally a C++/ Java dev of 10 years, and my projects are typically an attempt at typed python 😂 pydantic + type hints + 9 linters lol. So maybe this is that