Mypy: Ignore specific lines

[Shookit]

I don't know if this is intentionally omitted, or if I'm just not aware of the functionality, but is there any way to ignore mypy errors line-by-line?

For instance, one of the files I'm using mypy on works, but for certain lines...

graph.py, line 3: No module named 'numpy'
graph.py, line 4: No module named 'matplotlib.pyplot'
graph.py, line 5: No module named 'scipy.stats'
graph.py, line 155: Unexpected keyword argument "key" for "max"

...mypy gives errors incorrectly that I'd like to ignore (the modules do exist, and max does take the 'key' argument).

Is there any way to skip these lines, such as in a linter, or a way to hint to mypy that these are valid?

[rockneurotiko]

Check this issue #486 , right now you can't, but there are some things to do before to allow that.

[JukkaL]

This is something that I'd like to have and have thought about it a little. A potential approach is to use a special comment for this:

import numpy  # mypy: ignore

We could also support an if statement for this (this actually partially implemented already but completely undocumented):

from typing import MYPY

if not MYPY:
    import numpy

The value of MYPY would always be False at runtime, but when type checking it would be considered as a compile-time constant with value True that could be used for a kind of conditional compilation -- a if not MYPY block would be ignored by the type checker (but any newly defined names would be given the type Any, perhaps).

Or maybe we can support using a comment to ignore multiple lines:

# mypy: begin ignore
import numpy
import matplotlib.pyplot
import scipy.stats
# mypy: end ignore

Implementation of #486 would be awesome but it does not help when there are C extension modules. However, we may be able to automatically generate pure dynamically typed stubs for C extension modules automatically. @ashleyh started writing a stub generator (I have a clone at https://github.com/JukkaL/mypy-stubgen) but there hasn't been updates in a long time.

[spkersten]

I like annotations to instruct mypy to ignore something much more than having to change code by adding if not MYPY guards.

[JukkaL]

PEP 484 uses # type: ignore for ignoring type errors on particular lines, and mypy should support that. Also, using # type: ignore close to the top of a file should skip checking that file altogether.

[JukkaL]

Okay, now you can use # type: ignore to silence some errors. Example:

import foo # type: ignore
foo.f()  # okay

[CMCDragonkai]

If the expression being ignored is spread out across lines, the ignore annotation doesn't work.

    with subprocess.Popen(
            *args, bufsize=1, stderr=subprocess.PIPE, **kwargs) as proc: # type: ignore

[ilevkivskyi]

If the expression being ignored is spread out across lines, the ignore annotation doesn't work.

This is supported only on Python 3.8, on older versions you need to place the # type: ignore comment _exactly on the line where error appears_.

[and-semakin]

It would be nice to ignore code blocks like this, because with use of black it gets difficult to correctly place single type: ignore comment, for example:

def some_func(long_argument_name, another_long_argument_name) -> None:  # type: ignore
    pass

Now run black to format this code:

def some_func(
    long_argument_name,
    another_long_argument_name
) -> None:  # type: ignore
    pass

black has moved type: ignore comment on another line and now mypy fails. So after auto-formatting I have to manually replace the comment to the same line where def is located. Despite the fact that it looks like a bug in black, it would be convenient to have a way to disable type checking at once in the whole code block:

# type: begin ignore
def some_func(
    long_argument_name,
    another_long_argument_name
) -> None:
    # type: end ignore
    print("Now code formatter can't break my shitty code anymore!")

[MattOates]

@and-semakin this can also be resolved if like the pylint: disable directive you can just put a line comment by itself the line before to ignore the next line. Less likely to cause havoc than an open/close type semantics. What happens if someone moves some code or deletes the end ignore? etc.