Nicer output

I have mentioned this on gitter, but I think it might be a good idea to open an issue to track this. Current mypy output is a bit harsh. Compare (I know these are different kind of errors, but still)

(mypy-dev) ~/src/mypy [master] λ cat x.py 
from typing import Tuple
v: Tuple[int] = list(10)
(mypy-dev) ~/src/mypy [master] λ mypy x.py 
x.py:2: error: No overload variant of "list" matches argument types [builtins.int]

to

~/src/mypy [master] λ cat x.rs 
fn main() {
    let v: &[usize] = Vec::with_capacity("10");
}
~/src/mypy [master] λ rustc x.rs 
error[E0308]: mismatched types
 --> x.rs:2:42
  |
2 |     let v: &[usize] = Vec::with_capacity("10");
  |                                          ^^^^ expected usize, found reference
  |
  = note: expected type `usize`
             found type `&'static str`
  = help: here are some functions which might fulfill your needs:
          - .len()

error[E0308]: mismatched types
 --> x.rs:2:23
  |
2 |     let v: &[usize] = Vec::with_capacity("10");
  |                       ^^^^^^^^^^^^^^^^^^^^^^^^ expected &[usize], found struct `std::vec::Vec`
  |
  = note: expected type `&[usize]`
             found type `std::vec::Vec<_>`
  = help: here are some functions which might fulfill your needs:
          - .as_slice()

error: aborting due to 2 previous errors

Rustc output is specified here.

I don't have any ideas other than that we could start adding at least come colors. I'm pretty sure that we should keep the old format as an option, because it is useful for various tools like neomake, it drives current test-cases-as-data and simply some people might prefer that.

Even though I agree that some of mypy's errors confuse users, I'm not a big fan of that kind of ultra-verbose output. It's better to make some specific errors better while keeping the general style. I'm also not a big fan of colors (but I know I am in the minority there).

@gvanrossum

It would be useful to have better error messages, but I agree with @gvanrossum that just fixing specific errors that aren't very good should be enough. We might make certain error messages much longer but I'm not a fan of making every message verbose, as it arguably makes it slower for a human to scan the output from mypy.

I'm not saying we should have output as verbose as rustc. Rust needs it primarily because of steep learning curve associated with borrow checker - typing Python code is way easier.

I think we should go more into gcc direction:

~/src/mypy [slice-none] λ cat x.c
#include <stdlib.h>
int main(void) {
    char v = malloc("10");
}
~/src/mypy [slice-none] λ gcc x.c
x.c: In function ‘main’:
x.c:3:21: warning: passing argument 1 of ‘malloc’ makes integer from pointer without a cast [-Wint-conversion]
     char v = malloc("10");
                     ^~~~
In file included from x.c:1:0:
/usr/include/stdlib.h:427:14: note: expected ‘size_t {aka long unsigned int}’ but argument is of type ‘char *’
 extern void *malloc (size_t __size) __THROW __attribute_malloc__ __wur;
              ^~~~~~
x.c:3:14: warning: initialization makes integer from pointer without a cast [-Wint-conversion]
     char v = malloc("10");
              ^~~~~~

image

and we're actually close to that. Three things:

better messages itself
COLORS!
optionally print offending statement/expressions instead of just referencing line/col - I think it helps

Created a separate issues to discuss colors (#7410) and printing the offending line (#7411). This issue will continue to cover other suggestions, but I'd say that the linked issues are the highest-priority improvements.

I was also thinking something that might be nice is to make the output less dense. At least for me, it is much harder to read/scan the output of more than a dozen errors because it turns into a huge wall of text. This likely would require breaking things across lines however, and I could see that being problematic with the test suite :/

The main problem I have is with errors like "expression has type XXX, expected type YYY". Sometimes XXX and YYY are very long (e.g. List[Tuple[int, int, Dict[str, Tuple[str, str]]] and it's hard to even find where one ends and the other starts; it's also hard to compare them item by item (e.g. if the key type to Dict is bytes in one and str in the other. We could use color to highlight the types different than the rest of the message, and maybe we could even do some kind of diff between the two types and highlight the actual difference in red/green (like code diffs).

Some thoughts about very long errors:

Highlighting types and quoted strings in messages when using colors sounds helpful.
I like the idea of an aligned diff with colors, and maybe a ^ pointing to the first difference (useful if colors are disabled). This should probably only be enabled in some cases, such as when the types are long enough, and there is a common prefix (so finding the difference can be hard).
Maybe we should split some messages to multiple lines, but only if the types are very long. For example, we could show expression type and expected type each on a separate line after the main message. If we don't do this always, we likely wouldn't have to change many test cases.
We could show each file name only once like a header, on a separate line. Messages would be shorter since the file name would not be shown for each message, and the messages would be better aligned due to variable-length file paths.

I'm skeptical about formatting things differently depending on (e.g.) the size of the types. This makes things harder for tools that parse errors. So does breaking errors across lines. Though maybe those tools could be taught to only care about the error code, and further detail could be added as notes.

I feel like tools should not expect error messages to be easily parseable. We change them not infrequently, and with error codes I see no reason why they should even try to parse the messages?

We (or Ivan) have some ad-hoc scripts that grep for certain errors and auto-insert type-ignores. But that's probably going the way of the dodo.

On latest master, mypy looks pretty close to the gcc output when using --pretty

Navigation Menu

Repository navigation

Nicer output #3439

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Nicer output #3439

Description

Activity

gvanrossum commented on May 24, 2017

JukkaL commented on May 24, 2017

miedzinski commented on May 24, 2017

JukkaL commented on Aug 29, 2019

emmatyping commented on Aug 30, 2019

gvanrossum commented on Aug 30, 2019

JukkaL commented on Aug 30, 2019

gvanrossum commented on Aug 30, 2019

emmatyping commented on Aug 31, 2019

gvanrossum commented on Aug 31, 2019

hauntsaninja commented on Aug 3, 2022

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions