Hacker News new | ask | show | jobs
by stefanhoelzl 1780 days ago
mypy accepts much broader types then the concept I was proposing. Lets take this example:

  def foo(bar: Optional[float]) -> Optional[float]:
      return bar

  def test_foo():
      assert foo(5) == 5
It has 100% code coverage and mypy will accept it.

What I proposed will complain in this case, that you never tested `foo` with `None` or `float` as input parameters and that it never has seen `foo` returning `None` or `float`.

So even with 100% code coverage and mypy not complaining 'type coverage' could give you some hints that a) your tests are not extensive enough or b) your annotated types are too broad

1 comments

Yeah, but in practice you rarely (if ever) call foo() with a literal. In normal code you'll use variables or return values, and if they're annotated, mypy will catch mismatching types.

What you propose will certainly solve the issue when dealing with unannotated code, though.

Yes exactly, mypy will catch mismatching types. But in my example I do not have mismatching types, but still can detect an issue when testing a function which expects `Optional[float]` only with an `int`.

Regarding literals or annotated variables: mypy will detect mismatching types in both cases.