Ty misses required-field diagnostic for SQLModel (works for BaseModel)

[Duckling92]

Summary

Ty flags missing required fields for pydantic.BaseModel but not for sqlmodel.SQLModel subclasses, both using Pydantic v2.

Minimal repro

from __future__ import annotations

from pydantic import BaseModel
from sqlmodel import SQLModel


class ExamplePydantic(BaseModel):
    number: float


class ExampleSQLModel(SQLModel):
    number: float


ExampleSQLModel()  # ty: no error (bug)
ExamplePydantic()  # ty: error (good)

Expected

Expected: Both ExampleSQLModel() and ExamplePydantic() are flagged as missing required field number.
Actual: Only ExamplePydantic() is flagged, ExampleSQLModel() passes.

Environment

python: 3.11.10
sqlmodel: 0.0.27
OS: MacOS Tahoe (26.0.1)

Version

ty 0.0.1-alpha.21 (ef52a19 2025-09-19)

[carljm]

I am pretty sure the problem here is that SQLModel defines __new__ and __init__ with very permissive signatures: https://github.com/fastapi/sqlmodel/blob/main/sqlmodel/main.py#L789-L799

And I think if we see an explicitly-defined __new__ or __init__, we assume that takes precedence over the dataclass-transform-generated one. So we validate the constructor call against the permissive __new__ and __init__ signatures and see no error.

But in this case it looks like SQLModel is just passing the arguments through, so its __new__ is just a wrapper, and the preferred behavior would be to still validate the arguments against the dataclass-transform-generated constructor.

But it's a little tricky to determine under exactly which conditions we should make this assumption (that a constructor with permissive signature is just a pass-through.)

[carljm]

For reference, mypy and pyrefly both have the same behavior we do here (catching only the ExamplePydantic() error). Pyright catches both errors.

@erictraut do you happen to remember what heuristic or algorithm pyright uses here to decide that a custom constructor should be effectively ignored?

[erictraut]

Pyright isn't ignoring the custom __new__. It's overriding it with a synthesized __new__. Pyright synthesizes both an __init__ and a __new__ method for dataclasses. In the case of __new__, it synthesizes a method with the signature def __new__(cls: type[<class>], *args: Any, *kwargs: Any) -> <class>. If it didn't synthesize a __new__ and the dataclass didn't provide a custom __new__, then all calls to the constructor would be flagged as an error because object.__new__ would be used, and it doesn't support any parameters.

I'm not convicted that pyright's behavior is correct here.

It looks like ty is not synthesizing a __new__. If that's the case, how do you avoid the problem with object.__new__? I'm guessing that you're using a heuristic to skip this check?

from dataclasses import dataclass

@dataclass
class DC:
    number: int

reveal_type(DC.__new__) # def __new__(cls) -> Self@new
DC.__new__(DC, 1) # ty reports an error here
DC(1) # ty does not report an error here

Regardless, it would be preferable for SQLModel to have less permissive type annotations here.

[sharkdp]

It looks like ty is not synthesizing a __new__. If that's the case, how do you avoid the problem with object.__new__? I'm guessing that you're using a heuristic to skip this check?

Correct, we skip object.__new__ when __new__ is called implicitly: https://github.com/astral-sh/ruff/blob/75f3c0e8e6dcd52e8194f9831aef25fddb646685/crates/ty_python_semantic/src/types.rs#L3252

[carljm]

then all calls to the constructor would be flagged as an error because object.__new__ would be used, and it doesn't support any parameters.

But this problem with the signature of object.__new__ is not specific to dataclasses, so "synthesizing a __new__ method for dataclasses" wouldn't be a general solution to the problem. Does pyright actually synthesize a __new__ method in that form for all classes that would otherwise inherit object.__new__?

IIRC ty's approach (skipping object.__new__) is roughly based on what happens at runtime, which is that object.__new__ actually only enforces its signature when called on a type that overrides __new__ or that doesn't override __init__, otherwise it accepts any and all arguments without complaint.