You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Conformance Tests directives_type_ignore should probably allow Mypy-like type ignores #2126
The conformance test directives_type_ignore feels a bit weird since it disallows the Mypy syntax:
z: int = "" # type: ignore[<some-error-code>]
# It has the following line where the violation should be suppressed:
z: int = "" # type: ignore[additional_stuff]
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 other comments and linting markers:
# type: ignore # <comment or other marker>
I feel it is therefore not really clear if the conformance tests are correct or not and I would really like to avoid adding a flag to Zuban with the name --make-conformance-tests-pass. # type: ignore[misc] can also be found in numerous places in Typeshed.
I would just suggest allowing an error there.
There's also this line that should be ignored to the conformance tests:
y: int = "" # type: ignore - additional stuff
where I'm not sure if it's better to allow an error there, but I don't have an opinion there really. It might be useful to generate an error that the - additional stuff is not conformant with the spec that says we should use an additional comment. Mypy for example has the error Invalid "type: ignore" comment [syntax]. I'm however totally fine if the conformance tests disallow this.
I think the current tests accurately reflect the way the spec is worded currently. If you'd like to suggest a modification or clarification in the spec, you could propose a change and see what the community thinks.
My personal preference is that type checkers support # type: ignore as it's currently spec'ed and then provide their own variants if they want to allow for type-check-specific features like filters on specific error codes. That's the approach I took with pyright, and I think some other type checkers have followed the same approach. This approach has been difficult for mypy to implement because mypy relies on the Python parser and its special-cased support for # type: ignore comments. The mypy maintainers are considering switching to a separate parser, which would eliminate this limitation.
Activity
erictraut commentedon Dec 9, 2025
I think the current tests accurately reflect the way the spec is worded currently. If you'd like to suggest a modification or clarification in the spec, you could propose a change and see what the community thinks.
My personal preference is that type checkers support
# type: ignoreas it's currently spec'ed and then provide their own variants if they want to allow for type-check-specific features like filters on specific error codes. That's the approach I took with pyright, and I think some other type checkers have followed the same approach. This approach has been difficult for mypy to implement because mypy relies on the Python parser and its special-cased support for# type: ignorecomments. The mypy maintainers are considering switching to a separate parser, which would eliminate this limitation.davidhalter commentedon May 4, 2026
This was fixed by #2153