Comment by phailhaus
15 hours ago
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.
15 hours ago
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.
Dataclasses support optional fields and kwargs perfectly. Not sure what you are talking about.
I don't think you understand what Pydantic brings to the table or why people use it. It has lots more to do with serialization, complex validation and data mapping.
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.
Technically there is dataclass_transform [1]. It's an ungodly hack, I don't know how it passed PEP review. And support by type checkers is questionable. After TS python hints feels like rigid and total unsound mess.
[1]: https://docs.python.org/3/library/typing.html#typing.datacla...
There is a way to indicate whatever class attributes are defined, those are kwargs to the init function. For one, you can use `kw_only` on the dataclass decorator [1], alternatively you can use the `kw_only` arg on the field function [2].
[1]: https://docs.python.org/3/library/dataclasses.html#dataclass...
[2]: https://docs.python.org/3/library/dataclasses.html#dataclass...
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 =)