Exact error codes for mypy errors

[tushar-deepsource]

Feature

Pylint / Flake8 style, unique error codes to be shown with every error that mypy raises.

Pitch

Mypy currently has ~40 general error names, that are shown next to the error if you pass the --show-error-code flag to mypy. For eg:

$ cat sample.py
def foo(a: str) -> str:
    return '(' + a.split() + ')'

$ mypy sample.py --show-error-codes
sample.py:2: error: Unsupported operand types for + ("str" and "List[str]")  [operator]
Found 1 error in 1 file (checked 1 source file)

But in total there's at least 80 probably around 400 unique error messages, each for a different kind of error.

The idea

• Create a proper list of numeric error codes, say 001 though 080 for eg., identifying each error uniquely.
• Have the error code shown directly before the error message in mypy output, just like pylint, flake8, and others.

$ cat mytest.py      
def a():
    print(foo)

$ pylint mytest.py
************* Module mytest
mytest.py:1:0: C0114: Missing module docstring (missing-module-docstring)
mytest.py:1:0: C0103: Function name "a" doesn't conform to snake_case naming style (invalid-name)
mytest.py:2:10: E0602: Undefined variable 'foo' (undefined-variable)
[...]

$ flake8 mytest.py
mytest.py:1:1: D100 Missing docstring in public module
mytest.py:1:1: D103 Missing docstring in public function
mytest.py:2:11: F821 undefined name 'foo'

I've run the idea past @ethanhs and I'm told that this would be a great-to-have in mypy. I'm willing to contribute this, once I've run it past the mypy team 😄

cc @srijan-deepsource

[JukkaL]

This would be a major change and it needs more discussion before we can move forward. For example, right now one of the main use cases of error codes is to ignore specific errors using comments like # type: ignore[arg-type]. It's unclear how this proposal would support this. Breaking all existing # type: ignore[...] comments is not an option.

[erictraut]

It's not clear to me what problem you are trying to address with this proposal. Can you elaborate? Perhaps there are other ways to address it that would be less disruptive.

[tusharsadhwani]

@erictraut The problem I'm trying to address is that currently mypy is great as a standalone tool, but it's pretty hard to use it in conjunction with other tools, as its output is supposed to be human readable, but isn't computer-friendly at all. Having specific error codes per error opens up doors to better toolchain integrations.

@JukkaL Regarding type: ignore [...], I had an idea that would be backwards compatible. We can keep the current error code classes, while also adding unique issue codes for each issue raised. This would allow the previous type ignores to work, while also allowing more fine-grained ignores, such as ignoring exactly one of the errors that mypy throws.

For eg:

• type: ignore[valid-type] would ignore all invalid type annotation errors,
• type: ignore[unexpected-ellipsis] would ignore exactly one error: Unexpected "..."

[erictraut]

Is the main problem that you need to parse the human-readable output? I'm guessing that this feature would go a long way toward addressing that problem.

[tusharsadhwani]

Is the main problem that you need to parse the human-readable output?

The main problem I'm currently facing is that I want to be able to take action on each error that mypy throws. In case of pylint for example, I can simply use the unique error code it gives me to clearly identify the error, for eg. E0123. With mypy in its current form I'd need to write awkward regexes to accomplish this.

The unique error codes don't need to be visible by default, they could for eg. be activated by passing a flag, and the current behaviour stays the same.

[tusharsadhwani]

Also yes, I'd also love to add json/custom formatted output support to mypy as well :)

[JelleZijlstra]

What kind of action do you want to take on each error? Just trying to understand the use case.

[tusharsadhwani]

@JelleZijlstra at deepsource we provide users automatic code analysis, by providing meaningful issue descriptions, and also providing autofixes that will automatically fix the issue from their repo.

In order to do this, we need to be able to identify the exact issue being thrown at the given line:column, so that we can process it further. To do this we need a way to uniquely identify each error raised, which is usually through an error code. Hope that gives more context around my use case, I'm sure it's not the only possible use of it :)

[emmatyping]

I think this also will be quite useful for editor integration.

I think if backwards compatibility with the existing error codes could be maintained this could be accepted.

Unless @JukkaL you want to discuss the design more.

[picnixz]

I can suggest another use case. I usually write everything with a 79 character limit, but then, if there are some function calls that need to be suppressed for whatever reason, then I usually exceed the margin. With pylint, I can write something like:

# pylint: disable-next=error code or named error
bad_call()

so I don't have issues with comments exceeding the margin. With mypy, I unfortunately need to put the # type: ignore[...] on the same line (there was a discussion about having the pylint feature in mypy but I think it got rejected so I won't ask for it). I could suppress everything using # type: ignore but it is more of a hammer. With # type: ignore[EXXX] instead of # type: ignore[very-long-error-category], I could shorten that. An alternative would also be to support ruff-like statements # noqa: ERROR_CODE.

Finally, I think having exact error codes for each error would be suitable if we want to suppress specific errors without having to suppress the whole category it belongs to. I would also suggest using the same error codes as other linters if possible.