Allow type checkers to ignore specific error codes by davidhalter · Pull Request #2153 · python/typing · GitHub

Changes the error code from additional_stuff to assignment (as Mypy uses it).

This was the proposal Rebecca:

For # type: ignore[additional_stuff], I can see the argument for allowing an error about additional_stuff being an invalid code, but it seems tricky to update that line to allow both mypy’s and pyright’s behavior, since they’re so different. (Mypy also reports an assignment error, since that error code isn’t suppressed.) Maybe we could change it to:

z: int = "" # type: ignore[assignment]

so that the expected behavior in all type checkers is that there’s no error?

This will need changes in the spec text as well as the conformance suite, and it will need to be approved by the Typing Council. (Personally, I'm supportive of doing something like this, but haven't thought too much about the exact proposal yet.)

@JelleZijlstra What do you have in mind? My problem is that the spec is currently not specific about this at all (see this discussion) and I haven't gotten much feedback on where people would want to take this in the same thread.

Would you want to add something to the spec like this:

Any text following # type: ignore is ignored, provided there is at least one whitespace character after # type: ignore.

The only exception is the form # type: ignore[assignment], where the bracketed portion is used by mypy to restrict the ignored error codes. Other type checkers may ignore the bracketed codes and treat this form as equivalent to # type: ignore.

This is of course just my initial idea, any guidance is appreciated. The current spec doesn't really talk about this, so this should be more of an addition.

Something like that, yes. If the spec doesn't currently discuss this, that means we should add it.

The spec text shouldn't call out any specific type checker (like mypy). Instead, we should generically say that type checkers may use syntax like [code] to restrict the type ignore.

I have pushed a new update to the spec. It's just a small addition and I hope it reflects the general sentiment of the discussion in the typing discuss. As always I'm happy to integrate feedback.

@JelleZijlstra Would you mind looking at this spec change? I'd prefer at least a single opinion before I bring this to the typing council.

I removed the parts where I tried to specify how whitespace after # type: ignore works. Now it's just about error codes.

Co-authored-by: Carl Meyer <carl@oddbird.net>

What about also documenting that multiple error codes can be given (comma-separated), and unrecognized error codes should be ignored, if a type checker supports ignoring errors based on specific error code, as @ilevkivskyi suggested here.

Are there any other opinions on this? I'm pretty open to changes here.

I personally think that the comma separated form doesn't need to be specified explicitly.

unrecognized error codes should be ignored, if a type checker supports ignoring errors based on specific error code

Does this mean that Mypy would need to ignore the error code "undefined"? Currently it adds errors at least when using --warn-unused-ignores: https://mypy-play.net/?mypy=latest&python=3.12&flags=warn-unused-ignores&gist=27ebc9511f193a9f348b0235412cbcc9

I personally think that the approach outlined by @ilevkivskyi is the right one for multi-type-checker interoperability (much better than requiring totally separate ignore comments for each type checker), and I would be happy to fully specify it. But that would be a specification change that puts pyright and pyrefly out of conformance. If we did that, then I think the fulI behavior, including multiple comma separated codes, should be specified. I guess maybe we need feedback at least from pyrefly here: is the "always blanket ignore" behavior pyrefly's UX preference, or just something that was done to satisfy the previous conformance suite requirements?

But I think as long as the specification here is looser, as currently written (to accommodate both the pyright/pyrefly behavior and the mypy/zuban/ty behavior), it's not really important to document the multiple-error-codes handling, since effectively all this spec is now saying is that type checkers can do whatever they want with the information inside the brackets.

(Either way, I don't think the spec should _require_that type checkers be silent about unknown codes; it should be OK to warn users about them, as mypy does with --warn-unused-ignores. This is better behavior for users who aren't using multiple type checkers. Ideally users in multi-type-checker scenarios can turn off that warning if they don't want it.)

I'm happy with the current state of this PR as a first step, at least.

I'm fine with the current wording in this PR.

As for @ilevkivskyi's suggestion - I personally like it, but I'd like to run this by some other pyrefly devs who have thought a lot more than I have about configuration and adoption, to make sure this isn't incompatible with our tooling in some way that I'm missing.

As for @ilevkivskyi's suggestion - I personally like it, but I'd like to run this by some other pyrefly devs [...]

We discussed this and flagged a couple questions/concerns:

Are there any plans to standardize what lines errors are reported on? Without standardization there, this proposed change seems less useful, since multiple # type: ignores on different lines would still be needed to satisfy multiple type checkers.
Pyrefly has a --remove-unused-ignores flag to remove # pyrefly: ignore directives that are no longer used (useful for automated pyrefly version upgrades). This would be trickier in a world in which every type checker uses # type: ignore, since error codes could be used by other checkers rather than unused.

We should probably move this to a Discuss thread if someone wants to champion actually specifying the multiple-codes-in-type-ignore approach. I think the issues raised by the Pyrefly team are definitely real ones.

Regarding the first, I would just say that it's already a minority of type errors where checkers vary on the reported line, so the proposal is still a strict improvement for the ~90+% where type checkers naturally agree (because there's no real ambiguity). So some effort to standardize more of course wouldn't hurt, but this doesn't seem like a blocker.

Regarding the second, what ty does is expect all our codes in # type: ignore[...] to be prefixed with ty:, so we can still flag/remove all unused definitely-for-ty ignores, which is on par with what we can do with # ty: ignore. Whether we should ever remove (or flag as unused) ignores which might apply to other type checkers, is I think a UX question for each type checker. Might be useful for single-type-checker users, but definitely not desirable for multi-type-checker users, so at best it would need to be configurable.

…appen

I personally think that the approach outlined by @ilevkivskyi is the right one for multi-type-checker interoperability (much better than requiring totally separate ignore comments for each type checker), and I would be happy to fully specify it. But that would be a specification change that puts pyright and pyrefly out of conformance. If we did that, then I think the fulI behavior, including multiple comma separated codes, should be specified. I guess maybe we need feedback at least from pyrefly here: is the "always blanket ignore" behavior pyrefly's UX preference, or just something that was done to satisfy the previous conformance suite requirements?

But I think as long as the specification here is looser, as currently written (to accommodate both the pyright/pyrefly behavior and the mypy/zuban/ty behavior), it's not really important to document the multiple-error-codes handling, since effectively all this spec is now saying is that type checkers can do whatever they want with the information inside the brackets.

(Either way, I don't think the spec should _require_that type checkers be silent about unknown codes; it should be OK to warn users about them, as mypy does with --warn-unused-ignores. This is better behavior for users who aren't using multiple type checkers. Ideally users in multi-type-checker scenarios can turn off that warning if they don't want it.)

I'm happy with the current state of this PR as a first step, at least.

Co-authored-by: Carl Meyer <carl@oddbird.net>

I personally think that the approach outlined by @ilevkivskyi is the right one for multi-type-checker interoperability (much better than requiring totally separate ignore comments for each type checker), and I would be happy to fully specify it. But that would be a specification change that puts pyright and pyrefly out of conformance.

I'd also be happy to add that to the spec. I think if we want to do that we should ask for feedback on Discuss again, because people like @jorenham (scipy-stubs maintainer) might want to weigh in there for these multi-typechecker scenarios.

I'd also be happy to add that to the spec. I think if we want to do that we should ask for feedback on Discuss again, because people like @jorenham (scipy-stubs maintainer) might want to weigh in there for these multi-typechecker scenarios.

I don't have any particular preference to be honest. Anything that'll allow me to simplify things like

    # NOTE: These raise a `ValueError` if passed anything other than `ClusterNode`
    @override
    # pyrefly: ignore [bad-override]
    def __eq__(self, node: ClusterNode, /) -> bool: ...  # type: ignore[override]  # pyright: ignore[reportIncompatibleMethodOverride]  # ty: ignore[invalid-method-override]

(src), and I'll be happy.

I don't have any particular preference to be honest. Anything that'll allow me to simplify things like

    # NOTE: These raise a `ValueError` if passed anything other than `ClusterNode`
    @override
    # pyrefly: ignore [bad-override]
    def __eq__(self, node: ClusterNode, /) -> bool: ...  # type: ignore[override]  # pyright: ignore[reportIncompatibleMethodOverride]  # ty: ignore[invalid-method-override]

FWIW since we already changed ty's behaviour here, I believe you can already simplify it slightly to

    # NOTE: These raise a `ValueError` if passed anything other than `ClusterNode`
    @override
    # pyrefly: ignore [bad-override]
    def __eq__(self, node: ClusterNode, /) -> bool: ...  # type: ignore[override, ty:invalid-method-override]  # pyright: ignore[reportIncompatibleMethodOverride]

I'm not really sure how you handle situations like this, do I merge now that everyone has ticked off the box? I understand that the discussion around standardizing # type ignore[<content>] is still going on (where <content> could be defined as a comma separated list with namespaces and such). I'm supportive of that change, but I would prefer to merge this one first.

@davidhalter I think once you have five checkmarks on the typing-council issue and at least one approving review on the PR, you are good to merge.

FWIW since we already changed ty's behaviour here, I believe you can already simplify it slightly to

    # NOTE: These raise a `ValueError` if passed anything other than `ClusterNode`
    @override
    # pyrefly: ignore [bad-override]
    def __eq__(self, node: ClusterNode, /) -> bool: ...  # type: ignore[override, ty:invalid-method-override]  # pyright: ignore[reportIncompatibleMethodOverride]

This unfortunately will cause mypy to complain:

Unused "type: ignore[ty:invalid-method-override]" comment

This unfortunately will cause mypy to complain

This is a bug (or at least something that we want to change) in mypy.

It seems like merging this PR (even though it was green) broke the CI pipeline on main.

@JelleZijlstra Would you have time to look at this. It feels like a weird issue with Pyright when they do new releases:

https://github.com/python/typing/actions/runs/24907018988/job/72938873294

I can try to fix this, but I don't have that much time until Monday. And you seem to have implemented these checks in the CI. (Not blaming you here at all, thanks for your work!)

That's a fun one! We probably should have a post-processing step to remove such errors.

* main: Docs: Fix typo and grammar in type narrowing guide (python#2271) Update ty results for v0.0.35 (python#2282) Add pycroscope to the conformance suite (python#2278) Bump type checkers (python#2279) Update ty results for v0.0.33 (python#2275) conformance: allow consistent treatment of kwargs: Unpack[TD] (python#2272) bump mypy and pyright (python#2274) fix pyright version parsing (python#2273) Allow type checkers to ignore specific error codes (python#2153) Update pyrefly conformance results to v0.62.0 (python#2269) add ty to scripts/bump_type_checkers.py (python#2268)

davidhalter force-pushed the zuban-ignore branch from 57549ff to 8d74622 Compare January 19, 2026 12:45

srittau added the topic: conformance tests Issues with the conformance test suite label Jan 19, 2026

davidhalter mentioned this pull request Feb 10, 2026

Support mypy: ignore inline comments to suppress mypy errors python/mypy#12358

Open

Allow type: ignore error codes filtering

f4a919a

davidhalter force-pushed the zuban-ignore branch from 8d74622 to f4a919a Compare February 25, 2026 21:06

davidhalter marked this pull request as draft February 25, 2026 21:09

JelleZijlstra reviewed Mar 1, 2026

View reviewed changes

Comment thread docs/spec/directives.rst Outdated

srittau added the topic: typing spec For improving the typing spec label Mar 2, 2026

Try to improve the wording for the spec

6ce8087

JelleZijlstra reviewed Mar 2, 2026

View reviewed changes

Comment thread docs/spec/directives.rst Outdated

JelleZijlstra reviewed Mar 2, 2026

View reviewed changes

Comment thread docs/spec/directives.rst Outdated

Rephrase a bit of the spec

5cbcac4

davidhalter mentioned this pull request Mar 23, 2026

directives_type_checking.py: do not assert that type checkers must ignore all type errors in if not TYPE_CHECKING blocks #2210

Open

davidhalter added 2 commits April 14, 2026 02:31

Merge remote-tracking branch 'origin/main' into zuban-ignore

6856262

Avoid specifying how whitespace after # type: ignore works

ffc8e7c

davidhalter marked this pull request as ready for review April 14, 2026 00:39

carljm reviewed Apr 14, 2026

View reviewed changes

Comment thread docs/spec/directives.rst Outdated

Comment thread conformance/tests/directives_type_ignore.py Outdated

Comment thread conformance/tests/directives_type_ignore.py Outdated

davidhalter and others added 2 commits April 15, 2026 11:26

Update conformance/tests/directives_type_ignore.py

a0bc8ad

Co-authored-by: Carl Meyer <carl@oddbird.net>

Update docs/spec/directives.rst

614bf60

Co-authored-by: Carl Meyer <carl@oddbird.net>

davidhalter changed the title Allow Mypy/Zuban to ignore specific error codes Allow type checkers to ignore specific error codes Apr 15, 2026

Rerun the tests

ca781d2

carljm mentioned this pull request Apr 16, 2026

Spec change: Allow type checkers to ignore specific error codes python/typing-council#57

Closed

5 tasks

JukkaL reviewed Apr 16, 2026

View reviewed changes

Change the error code to a random error code and allow the error to h…

d37d815

…appen

carljm approved these changes Apr 16, 2026

View reviewed changes

JelleZijlstra approved these changes Apr 16, 2026

View reviewed changes

Update conformance/tests/directives_type_ignore.py

a6b55e4

Co-authored-by: Carl Meyer <carl@oddbird.net>

davidhalter merged commit 5d4cbb9 into python:main Apr 24, 2026
5 checks passed

davidhalter deleted the zuban-ignore branch April 24, 2026 22:57

JelleZijlstra mentioned this pull request Apr 25, 2026

fix pyright version parsing #2273

Merged

davidhalter mentioned this pull request May 4, 2026

Conformance Tests directives_type_ignore should probably allow Mypy-like type ignores #2126

Closed

AlexWaygood mentioned this pull request Jul 4, 2026

Consider best-effort supporting mypy error code names for some common cases astral-sh/ty#3127

Open

                 # type: ignore # <comment or other marker>
+              The form ``# type: ignore[...]`` may be used to suppress only type errors with a
+              given error code, though support for this is optional and may vary by type checker:

Allow type checkers to ignore specific error codes by davidhalter · Pull Request #2153 · python/typing · GitHub

Uh oh!

Allow type checkers to ignore specific error codes - #2153

Allow type checkers to ignore specific error codes#2153davidhalter merged 10 commits intopython:mainpython/typing:mainfrom davidhalter:zuban-ignoredavidhalter/typing:zuban-ignoreCopy head branch name to clipboard

Conversation

davidhalter commented Jan 19, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

JelleZijlstra commented Jan 22, 2026

Uh oh!

davidhalter commented Jan 22, 2026

Uh oh!

JelleZijlstra commented Jan 22, 2026

Uh oh!

davidhalter commented Feb 25, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

davidhalter commented Mar 1, 2026

Uh oh!

Uh oh!

Uh oh!

Uh oh!

davidhalter commented Apr 14, 2026

Uh oh!

Uh oh!

Uh oh!

Uh oh!

JukkaL Apr 16, 2026

Choose a reason for hiding this comment

Uh oh!

davidhalter Apr 16, 2026

Choose a reason for hiding this comment

Uh oh!

carljm Apr 16, 2026

Choose a reason for hiding this comment

Uh oh!

rchen152 Apr 17, 2026

Choose a reason for hiding this comment

Uh oh!

rchen152 Apr 24, 2026

Choose a reason for hiding this comment

Uh oh!

carljm Apr 24, 2026

Choose a reason for hiding this comment

Uh oh!

Uh oh!

carljm Apr 16, 2026

Choose a reason for hiding this comment

Uh oh!

davidhalter commented Apr 16, 2026

Uh oh!

jorenham commented Apr 16, 2026

Uh oh!

AlexWaygood commented Apr 24, 2026

Uh oh!

davidhalter commented Apr 24, 2026

Uh oh!

carljm commented Apr 24, 2026

Uh oh!

jorenham commented Apr 24, 2026

Uh oh!

ilevkivskyi commented Apr 24, 2026

Uh oh!

Uh oh!

davidhalter commented Apr 24, 2026

Uh oh!

JelleZijlstra commented Apr 25, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

10 participants

Allow type checkers to ignore specific error codes#2153
davidhalter merged 10 commits into
python:mainfrom
davidhalter:zuban-ignore

davidhalter commented Jan 19, 2026 •
edited
Loading

davidhalter commented Feb 25, 2026 •
edited
Loading