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

Cannot pass kwargs through for functions with default argument #7850

Closed
pedroceles opened this issue Nov 1, 2019 · 4 comments
Closed

Cannot pass kwargs through for functions with default argument #7850

pedroceles opened this issue Nov 1, 2019 · 4 comments

Comments

@pedroceles
Copy link

First, thanks a lot for this library!

This bug is probably related to #1969

def test1(**kwargs: int) -> None:
    test2(**kwargs)

def test2(a: bool=True, **kwargs: int) -> None:
    print(a, kwargs)

results in this error:

test_mypy.py:2: error: Argument 1 to "test2" has incompatible type "**Dict[str, int]"; expected "bool"

The inconvenient fix would be:

from typing import Mapping

def test1(**kwargs: int) -> None:
    temp = kwargs  # type: Mapping[str, int]
    test2(**temp)

def test2(a: bool=True, **kwargs: int) -> None:
    print(a, kwargs)

Python version: 3.5.3
Mypy version: 0.740

mypy.ini

[mypy]
python_version = 3.5
warn_return_any = True
warn_unused_configs = True
disallow_incomplete_defs = True
disallow_untyped_defs = True
@pedroceles pedroceles changed the title Can not pass kwargs through for functions with default argument Cannot pass kwargs through for functions with default argument Nov 1, 2019
@JelleZijlstra
Copy link
Member

I think mypy is right here: the code is unsafe. If you call test1(a=1), test2 would receive an int instead of a bool for its a parameter.

@ilevkivskyi
Copy link
Member

I think mypy is right here: the code is unsafe.

Yes, this code is technically unsafe, the error message is cryptic however, but we already have an issue to make it better, see #5382

@pedroceles
Copy link
Author

If that is the case there should be an error raised in the second example as well, shouldn't it?

@ilevkivskyi
Copy link
Member

If that is the case there should be an error raised in the second example as well, shouldn't it?

Yes, I am however not super worried about the inconsistency. You may open an issue about this however if you want to prohibit this (or retitle this one).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants