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.

[carljm]

Suggested change

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

[carljm]

tbh I think it would be more "fair" to not change this line to use the type code that matches mypy/zuban. There's no specified requirement that all type checkers must use the type code assignment for this situation. So I think all type checkers that do strict handling of ignores with error codes should equally rely on # E? on this line.

[davidhalter]

This is definitely fair. I'm indifferent here and will wait if there are any other opinions here.

[AlexWaygood]

I obviously don't have a vote here, but I agree with @carljm :)

ty has the same behaviour as zuban and mypy here but has different error codes. I would expect this change to result in ty being marked fully conformant with this file, just like mypy and zuban, but it is not because you're using a mypy/zuban-specific error code

[JelleZijlstra]

Yes, I think it might be best to actually use a completely made up error code.

# type: ignore[an-empty-str-is-not-an-int], for the type checkers with really specific error codes.

[davidhalter]

Oh nice, I didn't even realize that Ty was also affected by this. It feels like the change makes even more sense then. I changed it towards the random error code Jelle proposed.

[AlexWaygood]

yes, we changed our behaviour recently because we came to the conclusion that mypy's/zuban's behaviour was much more user-friendly for folks trying to run multiple type checkers on their codebase (not unusual for library authors)

[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