Why is this dataclasses inferred to be invariant?

[mezuzza]

Parameter here is inferred to be invariant and I can't for the life of me figure out why.

type ParameterSerializer = HeaderSerializer | PathSerializer | QuerySerializer | CookieSerializer

@dataclass(slots=True, frozen=True)
class Parameter[T: ParameterSerializer]:
    name: ParamName # Just a newtype of str
    required: bool
    description: str
    type: Type # this isn't typing.Type. It's a custom class
    serializer: T

path: Sequence[Parameter[PathSerializer]] = []
x: Sequence[Parameter[ParameterSerializer]] = path # T@Parameter is invariant.

And yet, when I try to recreate the same scenario, I can't get it to work.

type Bound = int | str


@dataclass(slots=True, frozen=True)
class Foo[T: Bound]:
    x: T


foo_ints: Sequence[Foo[int]] = []
x: Sequence[Foo[Bound]] = foo_ints # No problems

Any idea on how these are different?

[erictraut]

Your first code sample contains a bunch of symbols that are not defined in the code sample, so I'm unable to repro the problem. If I replace these undefined symbols with builtin counterparts like str, I don't see any type checking errors. Could you provide a minimal, self-contained example that demonstrates the behavior you're seeing?

Here's a tip that you might find useful: If you're using pyright within an IDE, you can hover over the type parameter in the class definition to see the inferred variance.

[mezuzza]

Ok, I'm really sorry. I was trying so hard to repro this and the problem was that I'd imported dataclass from attr instead of dataclasses. Don't know how that happened, but I must have accidentally hit the wrong import at some point.

I'd been trying to repro this so hard and couldn't (T_T) and that explains why. The tip actually helped quite a bit since in trying to copy all the classes into a separate file, I ended up not being able to repro the issue.

[mezuzza]

A separate question comes to mind - why the use of attr marks this as invariant, but I suppose that's an attr issue, not a pyright one.

[erictraut]

I was wondering that myself, so I dug into it. The difference is that attr default to order=True whereas the stdlib dataclass does not. When order=True, methods are synthesized for __lt__, __gt__, etc. The signature that pyright generates for these comparison operations uses a parameter annotation of other: Foo[T]. This causes the variance of T to be invariant.

I think it's better for these synthesized methods to use Self rather than Foo[T] in this case. This preserves the covariance of T. I've made this change, and it will be included in the next release of pyright.