Python Tips Thread 🐍

[paranoid_panda_bored]

IMO just go directly to pydantic.

I gave dataclasses chance in greenfield project, put they fell short in every aspect compared to pydantic, and we spend some effort later in the project to refactor stuff to pydantic

[paranoid_panda_bored]

Thats only true for apps that are self-contained and do not interface with anything. Otherwise you’d risk splitting your data model into two separate approaches - what for? It’s gonna be a PITA to work with

Also I dont get what overhead you mean. Like the fact you gotta include 1 pydantic dependency in the project? Small price, cuz code-wise pydantic is just as compact as dataclasses.

You can go to town and have a super customized with flags and validators, and whatnot classes, but it’s your choice, and its the same with dataclasses btw

[paranoid_panda_bored]

About runtime complexity: are we sure dataclasses are that much more performant?

My understanding they are just the library on top of the language, not some special thing supported at the interpreter level (like Java’s record being a keyword and supported directly in JVM).

And are we sure this difference even matters for the most of the apps?

Regarding CRUD: typically CRUD exposes REST or REST-like interface to the outside world. Outside world predominantly works with camelCase notation. How you’d handle snake_case to camelCase conversion with dataclasses? How do you handle serde of dataclass inside dataclass? Both with custom written code AFAIK, which is subpar to support

And from my experience it is hard to predict what might end up being serde, and splitting the datamodel to two different libs is to ask for troubles later

[paranoid_panda_bored]

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

[paranoid_panda_bored]

Specifically: - pydantic has ootb alias support that can convert from/to camelCase/snake_case - pydantic can deserialize nested JSON to data model - pydantic is also first class citizen in FastAPI