because now, with the added context [int, Any], the overload resolution is deemed ambiguous, resulting in reinferred_rvalue_type = tuple[Any, ...] here.
What is the intended result in this example?
(int, Any) (current master)
(int, int) (pyright)
(Any, Any) which we should get if we use the reinferred_rvalue_type properly.
For example, one could end up with (3) by adding a branch
ifisinstance(reinferred_rvalue_type, Instance) andreinferred_rvalue_type.type.fullname=="builtins.tuple":
# the type can change into variadic tuple if the added context picks a different overload# see testOverloadWithOverlappingItemsAndAnyArgument17 as an examplegeneric_type=reinferred_rvalue_type.args[0]
forlvinlvalues:
if (
isinstance(lv, NameExpr)
andisinstance(lv.node, Var)
andlv.node.typeisNone
):
lv.node.type=generic_typeelifisinstance(lv, StarExpr):
if (
isinstance(lv.expr, NameExpr)
andisinstance(lv.expr.node, Var)
andlv.expr.node.typeisNone
):
lv.expr.node.type=self.named_generic_type(
"builtins.list", [generic_type]
)
returnassertisinstance(reinferred_rvalue_type, TupleType)
Activity
randolf-scholz commented on Sep 16, 2025
Here is a case where this seems to matter: https://mypy-play.net/?mypy=latest&python=3.12&gist=f30386efbc0aebb9907f30ad9eac7edf
If we patch infer_constraints to give {1 <: B, 1 <: A} in both cases, this breaks during multiple rvalue check
mypy/mypy/checker.py
Line 4202 in dce8e1c
because now, with the added context [int, Any], the overload resolution is deemed ambiguous, resulting in reinferred_rvalue_type = tuple[Any, ...] here.
What is the intended result in this example?
For example, one could end up with (3) by adding a branch