Skip to content

Allow Mypy/Zuban to ignore specific error codes #2153

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.

Sign up for GitHub

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

Draft
davidhalter wants to merge 3 commits into
base: main
Choose a base branch
from
Draft

Allow Mypy/Zuban to ignore specific error codes #2153

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
f4a919a
Allow type: ignore error codes filtering
davidhalter Feb 25, 2026
6ce8087
Try to improve the wording for the spec
davidhalter Mar 2, 2026
5cbcac4
Rephrase a bit of the spec
davidhalter Mar 2, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
6 changes: 5 additions & 1 deletion conformance/tests/directives_type_ignore.py
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -10,8 +10,12 @@
# The following type violation should be suppressed.
y: int = "" # type: ignore - additional stuff

# The following type violations should not be suppressed.
y: int = "" # type: ignored # E: Unexpected word "ignored"
y: int = "" # type: ignored, foo # E: Unexpected comma

# The following type violation should be suppressed.
z: int = "" # type: ignore[additional_stuff]
z: int = "" # type: ignore[assignment]

# > In some cases, linting tools or other comments may be needed on the same
# > line as a type comment. In these cases, the type comment should be before
Expand Down
19 changes: 19 additions & 0 deletions docs/spec/directives.rst
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -73,6 +73,25 @@ other comments and linting markers:

# type: ignore # <comment or other marker>

Text following ``# type: ignore - some text`` is equivalent to
``type: ignore``, provided there is at least one whitespace character after it::

# Not valid because of the "d" after ignore; does not supress the type error
s: str = 1 # type: ignored
# Not valid because of the comma; does not supress the type error
Copy link
Member

@JelleZijlstra JelleZijlstra Mar 2, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What's the motivation again for this part? I'm not sure what we get out of separating the cases with and without the comma, or even why we allow random text after ignore at all.

Copy link
Contributor Author

@davidhalter davidhalter Mar 2, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The motiviation is that some people mentioned on discuss that allowing text after # type: ignore has a clear intent and we should therefore allow it.

I'm personally in the camp of being more strict here, # type: ignore foo would therefore add an error that this is an invalid type: ignore. But I feel like I'm in the minority.

I'm not sure what we get out of separating the cases with and without the comma, or even why we allow random text after ignore at all.

I'm also open to just dropping that particular case, not mentioning the comma case and leave type checkers room to deal with that in different ways. I don't think it's that important (and probably really rare in actual usage).

Rebecca mentioned:

We could require whitespace after the ignore. So # type: ignored would not be a valid ignore, but # type: ignore whatever would be.
(I checked what pyrefly does, and we require either whitespace or a “word boundary”

I'm fine with having it either way, but I think defining what a word boundary is in the spec is a bit difficult. I also think that allowing stuff like # type: ignore.foo is a bit weird.

Copy link
Member

@JelleZijlstra JelleZijlstra Mar 2, 2026 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't feel too strongly about the exact behavior but I'd prefer we have a precise spec here to remove ambiguity.

Copy link
Contributor Author

@davidhalter davidhalter Mar 2, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Whitespace is pretty strong, no? It seems like you want the comma to be added. How about we treat whitespace the same as ;, and ,? I feel like these are probably most likely to be a useful boundary. Everything else to me feels unnecessary. Do you have another idea how we could phrase it? I also don't have strong feelings.

I'm also questioning whether I should even try to add this to the spec. I am mostly trying to get the part about type ignore filters (type: ignore[assignment]) in here. This just felt like a natural addition which was under-specified. Would you recommend just removing that part focusing on the type ignore filters?

s: str = 1 # type: ignore, because I feel like it
# This is valid because of the whitespace and must suppress the type error
s: str = 1 # type: ignore because why not

The form of ``# type: ignore[...]`` may be used to filter errors depending on
the type checker:

- In ``# type: ignore[my_code1]``, a type checker may ignore the error code
``my_code1`` and choose to treat this form as equivalent to ``# type: ignore``.
- Alternatively in ``# type: ignore[my_code1]`` a type checker may suppress the
error only if the error cause matches the error code ``my_code1``.
- ``# type: ignore`` must always suppress all errors.

.. _`cast`:

``cast()``
Expand Down
Loading