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.
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.
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
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.
would you say the same of SQLModel? Which I think is an ideal solution (theoretically), better than SQLAlchemy
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.
> 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
I agree on the first part, but Pydantic is not important to Python. It's important to a lot of people, but it's absolutely unnecessary.
its the ideal way to do structured outputs with LLMs and Python has become the default language for AI applications. I would wager that structured outputs are probably the no.1 usecase in AL applications
attrs + cattrs is pretty close. I know it’s not in the stdlib, but dataclasses were modelled on attrs in the first place and using attrs + cattrs feels quite a bit more idiomatic than Pydantic.
[dead]
I'm curious what issues you've run into, do you happen to have GitHub links so I can have a look? (I'm a maintainer.)
Pydantic still sees multiple commits per week, which is less than it was at one point, but I'd say that's a sign of its maturity and stability more than a lack of attention.
My experience is that pretty frequently the LLM just refuses to actually supply json conforming to the model and summarizes the input instead. Even with several retries configured I still couldn't rely on it. I only spent an afternoon with it though so it's possible I'm just doing it wrong (either in how I'm prompting or in how I'm configuring pydantic-ai).
How recently was that? I made a few improvements earlier this month: https://news.ycombinator.com/item?id=45058214
If the issue is still showing on the latest version, seeing the Pydantic model/schema would be very helpful.
It was about a month ago. I'll take another swing at it and make an issue if I can't overcome it.
Thanks for being a proactive kind of maintainer. The world is better because of people like you.
how so? Was thinking of using it for my next project - would love to hear some of the risks