Comment by flanked-evergl
15 hours ago
Sadly, the question with both this and ty is: Does it support pydantic? If not, then it's not really helpful for many people, and right now AFAIK neither supports pydantic.
Pydantic is probably the problem here, but it is what it is.
Pyrefly actually does have (experimental) support for Pydantic! https://pyrefly.org/en/docs/pydantic/
Nice, did not know.
Why would they need to support pydantic when it uses standard annotations? I tried it with ty yesterday and it flagged issues as expected.
Pydantic does some pretty strange stuff which works as expected but confuses the type checker unless you use the pydantic plugin. https://docs.pydantic.dev/latest/integrations/mypy/
I see. Tried ty and it seemed to know about missing required args. But wasn't able to follow the Field directives.
Python's type system is the problem here, which cannot support even the native dataclass pattern and needs custom plugins written for each type checker.
The type system’s alright. It just gets especially tricky when you’re trying to check code which won’t exist until you run it. For instance, suppose you wanted to load your own module from a database with something like
It can’t know what you’re going to load until it actually does it.
Things which lean heavily into metaprogramming, typically ORMs or things like Pydantic, fall into that category. I can’t hold that against the type system.
I guess you didn't work with good type system then. Look for TS, for example. How it allows to make strong typing for pydantic-like libraries in FE world. All how it allows to type routers.
> I can’t hold that against the type system.
I think we should. Dataclasses have existed in Python for an extremely long time, and yet the type system doesn't support defining your own similar classes. Kwargs have also existed forever, but they forgot to support that and had to add TypedDict's much later. And it still doesn't properly support optional fields. There's a lot of stuff like this in the language which are unbelievably frustrating, because for some reason they implemented the syntax before implementing a typechecker. Everything has been hacked in ever since. I consider python's type system to be a lost cause, just hoping for someone to make the Typescript equivalent for Python.
1 reply →
I don't think this is really true, I think native data classes can do just about everything you need, it's just that you need some tooling around them to get the same as Pydantic offers. I'm pretty sure we are going to see better native dataclass support in Pydantic going forward.
Already there is some support in Pydantic for native dataclasses: https://docs.pydantic.dev/latest/concepts/dataclasses/
There is no facility in the type system to express the idea that "whatever class attributes are defined, those are kwargs to the init function". That's hacked in using extra typechecker plugins. That's why we're sitting around talking about if a particular typechecker "supports pydantic", rather than it just working.
2 replies →
I have used native dataclasses with pydantic starting with v1.5 and it’s only improved with the the newer 2.x releases.
Aside from basic inheritance and complex nested types, the pydantic ‘TypeAdapter’ is awesome for simply validating native dataclasses. It’s a little slow, but everything pydantic is =)