←back to thread

196 points vinhnx | 1 comments | | HN request time: 0.226s | source
Show context
iLoveOncall ◴[] No.45056540[source]
I really wish Pydantic invested in... Pydantic, instead of some AI API wrapper garbage.

I've been using it a lot lately and anything beyond basic usage is an absolute chore.

replies(3): >>45056749 #>>45057785 #>>45057990 #
dcreater ◴[] No.45057785[source]
I wish Python would improve to bridge the gaps between pydantic and dataclasses, so that we don't have to rely on pydantic. It's too foundational a piece to not be part of the core python anymore
replies(4): >>45058029 #>>45060570 #>>45060714 #>>45061676 #
globular-toast ◴[] No.45061676[source]
It's just de/serialisation. IMO if you feel totally dependent on a single library for doing this for you then you're doing too much in that layer. This should be a tiny thin layer right at the edge of your application just for getting data in/out. I've seen people build almost their entire application in Pydantic classes. You're doing it wrong.

I don't know why people like this pattern of "fat" classes with built in de/serialisation/persistence logic at all. It makes so much more sense to have that at the edge and build entities and/or value objects directly. Using stuff like Pydantic or Django ORM you either end up completely coupling domain logic to serialisation logic, or you end up manually writing data mappers to/from your domain when you could have just used, for example, cattrs or SQLAlchemy. I guess it's the "easy vs simple" thing.

replies(1): >>45070176 #
dcreater ◴[] No.45070176[source]
would you say the same of SQLModel? Which I think is an ideal solution (theoretically), better than SQLAlchemy
replies(1): >>45072631 #
1. globular-toast ◴[] No.45072631[source]
SQLModel is even worse as it couples everything together. It's only good for basically building a JSON interface on top of a database. I guess it could be useful for a very basic web app. But the moment you start needing logic on the backend beyond basic read/write permissions you're screwed. At that point you either rewrite or proceed to build a big ball of mud.

In my experience backends never stay simple enough for SQLModel so you might as well decouple from the get go. If it's literally just copy/paste between SQLAlchemy models and Pydantic just do the copy/pasting. Get an LLM to do it if you have to. It will be worth it in the long run. You'll want to change your db schema without breaking your API.