Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

issue with ParamSpec and Callable of Callables #16405

Closed
graingert opened this issue Nov 4, 2023 · 1 comment · Fixed by #16471
Closed

issue with ParamSpec and Callable of Callables #16405

graingert opened this issue Nov 4, 2023 · 1 comment · Fixed by #16471
Assignees
Labels
bug mypy got something wrong topic-paramspec PEP 612, ParamSpec, Concatenate

Comments

@graingert
Copy link
Contributor

graingert commented Nov 4, 2023

Bug Report
When using ParamSpec and passing a Callable that takes a Callable, mypy 1.6.0, 1.6.1 and master rejects the input, this is a regression from 1.5.1

To Reproduce

from typing import *

T_Retval = TypeVar("T_Retval")
P = ParamSpec("P")


def run(
    func: Callable[[], T_Retval],
    *args: object,
    backend: str = "asyncio",
) -> T_Retval:
    return func()


def run_portal():
    pass


def submit(
    func: Callable[P, T_Retval],
    /,
    *args: P.args,
    **kwargs: P.kwargs,
) -> T_Retval:
    return func(*args, **kwargs)


submit(
    run,
    run_portal,
    backend="asyncio",
)

https://mypy-play.net/?mypy=1.6.1&python=3.11&gist=e282d121f479fcb77ec89daeb2a07b60

Expected Behavior

Should pass

Actual Behavior

main.py:29: error: Argument 1 to "submit" has incompatible type "Callable[[Callable[[], T_Retval], VarArg(object), DefaultNamedArg(str, 'backend')], T_Retval]"; expected "Callable[[Callable[[], Any], str], T_Retval]"  [arg-type]

Your Environment

  • Mypy version used: 1.5.1 (passes) 1.6.1, 1.6.0, master (fails)
  • Mypy command-line flags:
  • Mypy configuration options from mypy.ini (and other config files):
  • Python version used: 3.11
@graingert graingert added the bug mypy got something wrong label Nov 4, 2023
@AlexWaygood AlexWaygood added the topic-paramspec PEP 612, ParamSpec, Concatenate label Nov 4, 2023
@ilevkivskyi
Copy link
Member

This may be caused by #15896, IIRC. It was kind of an intentional trade-of. We added support for some more common cases (e.g. generic apply with positional arguments) knowing this may cause some regressions for more tricky cases (e.g. those involving keyword-only arguments). The decision was to see what use cases people actually need, and add some special-casing accordingly.

Since this is quite a tricky thing, the fix will not be available in 1.7, even though this is technically a regression (unless I will find a low-risk solution), fix will probably be available in 1.8.

@ilevkivskyi ilevkivskyi self-assigned this Nov 4, 2023
ilevkivskyi added a commit that referenced this issue Nov 13, 2023
Fixes #16405
Fixes #16412

Imprecise argument kinds inference was added a while ago to support
various edge cases with `ParamSpec`. This feature required mapping
actual kinds to formal kinds, which is in general undecidable. At that
time we decided to not add much special-casing, and wait for some real
use-cases. So far there are two relevant issues, and it looks like both
of them can be fixed with simple special-casing: ignore argument
positions in subtyping if arguments can be matched by name. This adds
minor unsafety, and generally doesn't look bad, so I think we should go
ahead with it.

---------

Co-authored-by: Alex Waygood <[email protected]>
JukkaL pushed a commit that referenced this issue Nov 22, 2023
Fixes #16405
Fixes #16412

Imprecise argument kinds inference was added a while ago to support
various edge cases with `ParamSpec`. This feature required mapping
actual kinds to formal kinds, which is in general undecidable. At that
time we decided to not add much special-casing, and wait for some real
use-cases. So far there are two relevant issues, and it looks like both
of them can be fixed with simple special-casing: ignore argument
positions in subtyping if arguments can be matched by name. This adds
minor unsafety, and generally doesn't look bad, so I think we should go
ahead with it.

---------

Co-authored-by: Alex Waygood <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug mypy got something wrong topic-paramspec PEP 612, ParamSpec, Concatenate
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants