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

Using same-name stubs is counterproductive #9156

Closed
ghost opened this issue Jul 16, 2020 · 1 comment
Closed

Using same-name stubs is counterproductive #9156

ghost opened this issue Jul 16, 2020 · 1 comment

Comments

@ghost
Copy link

ghost commented Jul 16, 2020

  • Are you reporting a bug, or opening a feature request?
    A bug / documentation / feature request, pending on what is expected.

  • Please insert below the code you are checking with mypy,
    Repo: https://github.com/vylmen/mypy-stubs-issue

  • What is the actual behavior/output?
    https://github.com/vylmen/mypy-stubs-issue/blob/master/results.txt

  • What is the behavior/output you expect?
    I expect the same errors to show up for coords.py as they do with nostub.py.

  • What are the versions of mypy and Python you are using?
    mypy 0.782, python 3.7.7. Did not check master, but will do if authors believe this behavior changed.

  • What are the mypy flags you are using? (For example --strict-optional)
    mypy.ini is in repo

So in short, coords.py is not typechecked (reveal_type is not printed for the file) using the definitions of coords.pyi. I don't see this mentioned in the docs and therefore I'm hoping it's a bug, but if this is unimplemented but desired behavior and unlikely to change - then a note in the docs needed.

@JukkaL
Copy link
Collaborator

JukkaL commented Jul 22, 2020

If there is a stub, mypy won't check the file. There is an existing issue about this: #5028. Closing as duplicate.

@JukkaL JukkaL closed this as completed Jul 22, 2020
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

1 participant