[Uberphallus]

While not exactly the same, you can obtain the same benefits with mypy.[0] It will perform all of what you say staticaly, without any test, though obviously it will not be smart enough when you use libraries that aren't using annotated types. But if you test for those, then you obtain 100% of the functionality that you described, unless I misunderstood something.

[0] https://mypy.readthedocs.io/en/stable/

[stefanhoelzl]

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

[Uberphallus]

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.

[stefanhoelzl]

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.