Incompatible ParamSpecs are not reported as issue #17766

Activity

1. pfaion

   added

   bugmypy got something wrongmypy got something wrong

   on Sep 13, 2024
2. pfaion

   changed the title [-]Incompatible ParamSpecs are not causing any issue[/-] [+]Incompatible ParamSpecs are not reported as issue[/+] on Sep 13, 2024
3. sobolevn

   added

   topic-paramspecPEP 612, ParamSpec, ConcatenatePEP 612, ParamSpec, Concatenate

   topic-type-variables

   on Sep 15, 2024
4. sterliakov commented on Feb 5, 2025

   

   sterliakov

   on Feb 5, 2025

   Last edited by sterliakov

   Collaborator

   More actions

   I'm not sure what the right course of action is here.

   First of all, P in the snippet can be satisfied by def _(x: Never) -> None, and that's exactly how mypy solves these constraints. Function with such signature can exist, so formally there is no bug.

   def foo(cb1: Callable[P, None], cb2: Callable[P, None]) -> Callable[P, None]:
       pass
     
   def my_callback_1(x: int) -> None:
       pass
   
   def my_callback_2(x: str) -> None:
       pass
   
   reveal_type(foo(my_callback_1, my_callback_2))  # N: Revealed type is "def (x: Never)"

   mypy does detect truly non-overlapping signatures (e.g. def f(x: int) -> None and def g(*, y: str) -> None are rejected in foo(f, g)). It doesn't:(

   However, such functions are of rather limited use (assert_never is one of them), and the requested behaviour is more intuitive and useful. This behaviour certainly needs to be formalized first: should that be "all arguments inferred to Never"? "at least one argument inferred to Never"? Something else?

   Current spec does not explicitly define incompatible ParamSpec caused by one or more args with constraints satisfied only by bottom type:

   Just as with traditional TypeVars, a user may include the same ParamSpec multiple times in the arguments of the same function, to indicate a dependency between multiple arguments. In these cases a type checker may choose to solve to a common behavioral supertype (i.e. a set of parameters for which all of the valid calls are valid in both of the subtypes), but is not obligated to do so.

   # Quoted from typing spec
   P = ParamSpec("P")
   
   def foo(x: Callable[P, int], y: Callable[P, int]) -> Callable[P, bool]: ...
   
   def x_y(x: int, y: str) -> int: ...
   def y_x(y: int, x: str) -> int: ...
   
   foo(x_y, x_y)  # Should return (x: int, y: str) -> bool
                  # (a callable with two positional-or-keyword parameters)
   
   foo(x_y, y_x)  # Could return (a: int, b: str, /) -> bool
                  # (a callable with two positional-only parameters)
                  # This works because both callables have types that are
                  # behavioral subtypes of Callable[[int, str], int]
   
   
   def keyword_only_x(*, x: int) -> int: ...
   def keyword_only_y(*, y: int) -> int: ...
   foo(keyword_only_x, keyword_only_y) # Rejected

   There's nothing technically challenging in changing this behaviour:

   diff --git a/mypy/applytype.py b/mypy/applytype.py
   index e87bf939c..e443f98db 100644
   --- a/mypy/applytype.py
   +++ b/mypy/applytype.py
   @@ -43,6 +43,10 @@ def get_target_type(
        if isinstance(p_type, UninhabitedType) and tvar.has_default():
            return tvar.default
        if isinstance(tvar, ParamSpecType):
   +        if isinstance(p_type, Parameters) and any(isinstance(get_proper_type(p), UninhabitedType) for p in p_type.arg_types):
   +            if skip_unsatisfied:
   +                return None
   +            report_incompatible_typevar_value(callable, type, tvar.name, context)
            return type
        if isinstance(tvar, TypeVarTupleType):
            return type