Allow Mypy/Zuban 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.

[JelleZijlstra]

I'm not sure I follow this line. The spec should primarily say how type checkers should behave, not what it's good for. Can you make sure the spec text makes it very precise exactly what behavior is expected?

[JelleZijlstra]

I would expect the behavior to be something like this:

• # type: ignore must ignore all errors
• # type: ignore[code] may ignore errors, depending on the type checker.

That is, pyright's behavior of ignoring the code and always ignoring errors remains conformant, but mypy's behavior of ignoring the error only when the code matches newly becomes conformant.

We'll also need to be clear about what the following do:

s: str = 1  # type: ignored
s: str = 1  # type: ignore, because I feel like it
s: str = 1  # type: ignore because why not