Allow type checkers to ignore specific error codes

[davidhalter]

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?

[JelleZijlstra]

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.)

[davidhalter]

@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.

[JelleZijlstra]

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.

[davidhalter]

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.

[davidhalter]

@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.

[davidhalter]

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

[JukkaL]

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.

[davidhalter]

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

[carljm]

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.

[carljm]

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.

[davidhalter]

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.

[jorenham]

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.