List invariance seems to be interpreted inconsistently

[Ruby (cardinal-bin)]

I think the simplest way to explain this is with an example:

from dataclasses import dataclass

@dataclass
class Type1[T]:
    attr: T

@dataclass
class Type2[T]:
    attr: list[T]

a: Type2[str | Type1[str]]          = Type2(['foo'])
b: Type2[str | Type1[str]] | str    = Type2(['foo'])

In this example, a is acceptable according to Pylance/pyright, however b is not:

Type "Type2[str]" is not assignable to declared type "Type2[str | Type1[str]] | str"
  Type "Type2[str]" is not assignable to type "Type2[str | Type1[str]] | str"
    "Type2[str]" is not assignable to "Type2[str | Type1[str]]"
      Type parameter "T@Type2" is invariant, but "str" is not the same as "str | Type1[str]"
    "Type2[str]" is not assignable to "str"

It seems that although pyright is happy that, without the union, list[str] can be assigned to list[str | SomeOtherType], once the union is included it is not. Most explanations of invariance that I have read suggest that list[str] is not a subtype of list[str | SomeOtherType], however when I try the following I get no issues:

class Animal:
    pass

class Dog(Animal):
    pass

animals: list[Animal] = [Dog()]

I'm still grappling with the concept of invariance personally but it does seem that the inference of the type of [Dog()] is somehow not inconsistent with list[Animal], however if I were to make it explicitly list[Dog], I will get an error. Whatever that inference is, the same thing happens with Type2(['foo']), but ONLY when the type doesn't include the union. In the latter example, it is inferred differently.

Or at least, that's what I think is happening.

[Aymen Hmaidi (aymenhmaidiwastaken)]

Your last paragraph is the right answer — "whatever that inference is, the same thing happens with Type2(['foo'])". Invariance is being applied consistently in every one of these cases. What changes is whether the declared type gets to influence how the argument is inferred in the first place.

Without a declared type to work from, that call infers as you'd expect:

reveal_type(Type2(['foo']))     # Type2[str]

['foo'] on its own is list[str], so T solves to str. Now compare the two assignments:

• a: Type2[str | Type1[str]] = Type2(['foo']) — pyright takes the declared type as the expected type for the call, pushes it inward, and infers the list literal as list[str | Type1[str]]. So T solves to str | Type1[str], which matches the declaration exactly and invariance is satisfied.
• b: Type2[str | Type1[str]] | str = Type2(['foo']) — the expected type is a union, that propagation doesn't happen, and the call is inferred bottom-up as Type2[str]. Then it's checked against each union member, and Type2[str] vs Type2[str | Type1[str]] fails on invariance, exactly as the message says.

So it's not that invariance is stricter in the second case. It's that the second case never gets the chance to infer str | Type1[str] at all, and by the time invariance is checked the type argument is already wrong.

Your list[Animal] = [Dog()] example is the same mechanism. That works because the declared type reaches the list literal and infers it as list[Animal], not because list[Dog] is a subtype of list[Animal]. Take the literal away and true invariance shows up:

dogs: list[Dog] = [Dog()]
animals: list[Animal] = dogs
# error: "list[Dog]" is not assignable to "list[Animal]"
#        Type parameter "_T@list" is invariant

Which is what you suspected when you said making it explicitly list[Dog] would error.

I poked at where the boundary actually sits, on pyright 1.1.411:

@dataclass
class Bare[T]:   attr: T
@dataclass
class Nested[T]: attr: list[T]

n1: Nested[str | Other]                = Nested(['foo'])   # ok  - not a union
b1: Bare[str | Other]                  = Bare('foo')       # ok

b2: Bare[str | Other] | int            = Bare('foo')       # ok  - union, bare T
b3: Bare[list[str] | Other] | int      = Bare(['foo'])     # ok  - union, list argument

n2: Nested[str | Other] | int          = Nested(['foo'])   # ERROR
n3: int | Nested[str | Other]          = Nested(['foo'])   # ERROR - order irrelevant
n4: Nested[str | Other] | None         = Nested(['foo'])   # ok   - Optional

Two things worth pulling out. A bare T survives a union expected type fine (b2, b3) — it's specifically a type parameter nested inside an invariant container that doesn't. And | None behaves differently from | int (n4 vs n2), which fits X | None being narrowed to X before the expected type is applied, where a general union has no single member to pick.

If you want it to work as written, give the inference something to hold onto:

lit: list[str | Type1[str]] = ['foo']
e: Type2[str | Type1[str]] | str = Type2(lit)                        # ok

f: Type2[str | Type1[str]] | str = Type2[str | Type1[str]](['foo'])  # ok

The second is the one I'd reach for — it says exactly what you mean at the call site and doesn't need a temporary.

Whether the union case ought to propagate the expected type inward the way the non-union case does is a design question rather than something I can answer from the outside, and the | None difference makes it a reasonable thing to ask about. Worth keeping the thread open for Eric Traut (@erictraut) on that specific point.