[flanked-evergl]

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.

[ocamoss]

Pyrefly actually does have (experimental) support for Pydantic! https://pyrefly.org/en/docs/pydantic/

[flanked-evergl]

Nice, did not know.

[mixmastamyk]

Why would they need to support pydantic when it uses standard annotations? I tried it with ty yesterday and it flagged issues as expected.

[flanked-evergl]

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/

[mixmastamyk]

I see. Tried ty and it seemed to know about missing required args. But wasn't able to follow the Field directives.

[phailhaus]

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.

[kstrauser]

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

  foo = eval(result)

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.

[phailhaus]

> 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.

[flanked-evergl]

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.

[phailhaus]

kwargs are not dataclasses, they are dicts. TypedDict was shoehorned in later to allow typing dicts, but they are so poorly designed that you can't mark individual fields as optional.

[bvrmn]

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.

[flanked-evergl]

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/

[phailhaus]

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.

[bvrmn]

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...

[flanked-evergl]

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...

[phailhaus]

That's only for dataclasses, you can't implement your own class like this without implementing it as a dataclass, because the typechecking for it is hacked in as a custom plugin.

What I'm trying to point out is that these features exist in core Python and yet the type system they built can't express it. By contrast, TypeScript is designed in such a way that you can implement everything yourself without having to write "custom typescript checker plugins".

[kitotik]

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 =)