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

documentation for module-level # type: ignore is unclear #7839

Closed
bwo opened this issue Oct 31, 2019 · 4 comments · Fixed by #13512
Closed

documentation for module-level # type: ignore is unclear #7839

bwo opened this issue Oct 31, 2019 · 4 comments · Fixed by #13512
Labels
bug mypy got something wrong priority-0-high topic-type-ignore # type: ignore comments topic-usability

Comments

@bwo
Copy link
Contributor

bwo commented Oct 31, 2019

My expectation of a module-level # type: ignore comment is that it will skip typechecking of everything in the module; i.e., everything would be given the type Any.

The description in the documentation such a comment "has the effect of ignoring the entire module.", is, I think, consistent with that impression, since what "ignoring" means earlier in the documentation has been basically skipping typechecking.

What it actually does, though, seems to be to cause mypy to quite literally ignore the module: it is just skipped entirely, with the result that you can't import names defined in that module in another one:

(.venv3) BenW ~ 02:10:35 $ cat foo/a.py
# type: ignore

class A(object):
    pass
cat(.venv3) BenW ~ 02:10:45 $ cat foo/b.py
from foo.a import A

def b(a):
    # type: (A) -> int
    return len(str(type(a)))

print(b(A()))
(.venv3) BenW ~ 02:10:47 $ mypy foo
foo/b.py:1: error: Module 'foo.a' has no attribute 'A'
Found 1 error in 1 file (checked 3 source files)

This makes the feature somewhat less useful IMO, but also, I think it could be clearer in the docs that that's what it does.

@brandtbucher
Copy link
Member

The actual implementation is that mypy marks the entire module as unreachable... as if the whole thing were indented inside of an if False: block. This is a side-effect of that change that I hadn't considered, though.

Perhaps modules should grow something like an is_ignored flag, which is checked when errors are reported, similar to how the module's ignored lines are checked. That could also mean that we report these if --warn-unused-ignores is enabled and there are no errors in the file. We can then also handle the various cases arising where there are other ignored lines in the file as well.

If we agree that this is the correct path forward, I can work on this.

@JukkaL
Copy link
Collaborator

JukkaL commented Nov 1, 2019

Mypy has the ignore_errors option. Maybe a top-level # type: ignore should turn it on for the module being type checked? This already works and allows names to be imported:

# mypy: ignore-errors
x = 1 + ''  # No error reported

@JukkaL JukkaL added bug mypy got something wrong priority-0-high topic-usability labels Nov 1, 2019
@brandtbucher
Copy link
Member

Agreed, they're functionally identical. I can take this.

@fluggo
Copy link

fluggo commented Dec 30, 2019

I am also suffering from this bug; a file marked # type: ignore[no-redef] is being treated as if nothing is defined in it.

@AlexWaygood AlexWaygood added documentation topic-type-ignore # type: ignore comments and removed documentation labels Mar 27, 2022
hauntsaninja added a commit to hauntsaninja/mypy that referenced this issue Aug 25, 2022
Per-module error codes were added in python#13502, let's recommend using them.

The existing type ignore behaviour is pretty unintuitive; I think most
people actually want `# mypy: ignore-errors`. There are probably people
depending on the current behaviour though.

Fixes python#13435, fixes python#12076, fixes python#11999, fixes python#11027, fixes python#9318,
fixes python#7839
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug mypy got something wrong priority-0-high topic-type-ignore # type: ignore comments topic-usability
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants