Introduction

If you want mypy to ignore one specific line, the standard tool is an inline # type: ignore comment on that line. That tells mypy to suppress type errors there without disabling checking for the rest of the function, file, or project.

Use # type: ignore on the Exact Line

The simplest form looks like this:

1from typing import Any
2
3value: int = "not really an int"  # type: ignore
4print(value)

Mypy will skip the type error on that line only.

This is useful when:

• a third-party library has incomplete type hints
• dynamic behavior is intentional and hard to express cleanly
• you are migrating legacy code gradually

The key benefit is scope. You are suppressing exactly one line instead of weakening type checking for a whole file.

Prefer Error-Code-Specific Ignores When Possible

Mypy also supports targeted ignores that specify which error code should be suppressed. This is better than a blanket ignore because it documents intent and prevents unrelated type errors on the same line from being hidden.

Example:

1from typing import Any
2
3def takes_int(value: int) -> None:
4    print(value)
5
6raw_value: Any = "5"
7takes_int(raw_value)  # type: ignore[arg-type]

Now only the arg-type complaint is ignored. If another kind of mypy problem appears on that line later, mypy can still report it.

This is usually the best long-term style for production code because it keeps suppressions narrow and self-explanatory.

Use the Ignore Only Where the Dynamic Behavior Lives

A common mistake is placing # type: ignore far away from the actual type problem. The cleaner approach is to attach it to the line that mypy is flagging.

For example, if the issue is a missing attribute on a third-party object:

plugin.run_custom_hook()  # type: ignore[attr-defined]

That makes it obvious what you are suppressing and why.

Another good pattern is to isolate the dynamic part in a small helper function rather than scattering ignores across business logic:

1from typing import Any
2
3
4def call_plugin_hook(plugin: Any) -> None:
5    plugin.run_custom_hook()  # type: ignore[attr-defined]

This keeps the rest of the codebase more strictly typed.

Know When an Ignore Is the Wrong Fix

Sometimes # type: ignore is a helpful escape hatch. Sometimes it is covering up a typing problem that should be solved properly.

For example, this code should probably be typed, not ignored:

def greet(name):
    return "hello " + name

If mypy complains later, adding an ignore is not the best solution. A proper annotation is:

def greet(name: str) -> str:
    return "hello " + name

Likewise, if a library lacks stubs, adding a protocol, cast, or better wrapper may be cleaner than a permanent ignore.

So the right question is not only "how do I silence mypy here," but also "is this line truly exceptional enough to deserve an ignore."

Common Pitfalls

The biggest mistake is using plain # type: ignore everywhere instead of narrowing the suppression to a specific error code. Broad ignores hide more than you intend.

Another issue is leaving old ignore comments behind after the code has been refactored. Over time, those comments can mask new problems that no longer deserve suppression.

Developers also sometimes place the comment on the wrong line and then wonder why mypy still reports the error. The ignore must be attached to the exact line mypy is checking.

Finally, do not use inline ignores as a substitute for writing real types. If the code can be expressed accurately with annotations, casts, protocols, or wrappers, that is usually the better fix.

Summary

• The standard way to ignore one line in mypy is # type: ignore.
• Prefer targeted forms such as # type: ignore[arg-type] when possible.
• Put the ignore on the exact line that triggers the error.
• Use ignores for genuinely exceptional dynamic cases, not as a default typing strategy.
• Revisit old ignore comments periodically so they do not become permanent blind spots.