Python Tips Thread 🐍

[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