Type inference on tuple literals is too specific which messes with invariant types.

[estheruary]

Describe the bug
Because the type inference on tuples is the most specific type is fails to validate correctly typed code when interacting with invariant (and I assume also contravariant but I didn't test) types.

To Reproduce

def get_list_of_tuples_of_strings() -> list[tuple[str, str]]:
    return [("Foo", "Bar")]

mylist = [("Hello", "World")] + get_list_of_tuples_of_strings()

/path/to/test.py:4:10 - error: Operator "+" not supported for types "list[tuple[Literal['Hello'], Literal['World']]]" and "list[tuple[str, str]]"
    Operator "+" not supported for types "list[tuple[Literal['Hello'], Literal['World']]]" and "list[tuple[str, str]]" (reportGeneralTypeIssues)

Expected behavior
The type of the tuple is inferred to be tuple[list[str,str]] instead of tuple[list[Literal['Hello'], Literal['World']]].

VS Code extension or command-line
Command line version 1.1.165

Additional context
Technically speaking this is documented behavior in the type inference but the reason I'm submitting it as an issue is because there is no non-awkward to annotate without creating a tmp variable just to make pyright infer the right type.

It seems to be specific to tuples, I thought that maybe the type inference on covariant types would always be "most specific" as well so I tried set and frozenset because why not and it validated.

Actually it seems specific to just tuple literals. If you replace [("Hello", "World")] with [tuple(("Hello", "World"))] it also validates.

[erictraut]

Yes, this behavior is specific to tuples, and it's the intended behavior. When it comes to inference heuristics, there's never a single approach that works in all cases. We've tuned the heuristics in pyright based on significant feedback from users. Unlike other mutable collection types like lists, dicts and sets, tuples are special in that they are immutable and the type system is able to represent the type of each element independently. That is why the inference heuristics are somewhat different for tuples.

The problem you're raising occurs when you combine tuples with other covariant types. As you've pointed out, the recommended solution in this case is to introduce a temporary variable.

For full details about the inference rules used in pyright, refer to this documentation.

[zooba]

Came here to report the same thing.

There's nothing wrong with the tuple inferencing, the problem is with the list inferencing. I'm not sure exactly what the correct rule should be, but I definitely don't want a list to be inferred to only be able to contain a single literal (which is essentially what a tuple containing only literals is).

The normal/intended use of lists is to contain different values of the same type. I shouldn't have to switch to using explicit type hints to achieve this.

[erictraut]

After much deliberation, I've decided to revisit this issue and change the way that pyright infers tuple expressions. In particular, when a tuple expression is embedded within another container (list, dict, set, or tuple) expression, the type checker will no longer retain literal values for the tuple. This change will be included in the next release of pyright.

[erictraut]

This is included in pyright 1.1.365.