Honestly I think this is my main issue with it. I have the same feelings about Liquid Haskell having a separate executable to check the liquid types. It's not the worst... but not ideal.
> The maintainers of mypy are python core developers, so it's not quite two sets of developers. :-)
Shows you what I know haha.
Still, there's no guarantee that it'll always be the same developers. And even then, it's two separate development cycles. MyPy could fall behind someday or something. Just something to think about!
> One of the benefits of optional typing is we can automatically add type annotations from runtime observation.
This has a high coolness factor but is not very sound, because it'll require writing good tests that allow you to make those observations in the first place, right? This is adding to the total test-writing workload of the user, instead of a statically typed language where you just get all of this for "free".
> Mypy supports structural subtyping currently.
I didn't realize this! That's good! Clearly I need to do more research before commenting haha.
This does appear to require an additional external dependency though (the `typing_extensions` module), which is too bad.
> Do people not run tests much in more-static languages?
You do, but the tests you need are different. You don't need to test that all inputs are valid by type (checking for runtime type errors in Python, for example), because type correctness is guaranteed when you compile.
So instead, you just have to write tests for functionality.
In a dynamically typed language, you need both to really ensure you're covered. (Or else you're just relying on invariants that people obey, which is... risky.)
> `typing.Protocol` is in Python 3.8.
Ah! Excellent. Glad to hear it! I will certainly be making use of that haha.
> Do people not run tests much in more-static languages?
Sure we do :-) but most projects would be lucky to reach something like 70% test coverage. You can't derive 100% type coverage from that. You can get 100% type coverage with a good typechecker.
Also, PHP has a nice approach here, type declaration errors can (essentially) be run-time file parse errors depending on your settings, so even if there aren't tests covering everything, if the coverage is decent enough to hit every file (I'll roughly throw out ~40% if it's a mature code base) then you're probably safe.
Honestly I think this is my main issue with it. I have the same feelings about Liquid Haskell having a separate executable to check the liquid types. It's not the worst... but not ideal.
> The maintainers of mypy are python core developers, so it's not quite two sets of developers. :-)
Shows you what I know haha.
Still, there's no guarantee that it'll always be the same developers. And even then, it's two separate development cycles. MyPy could fall behind someday or something. Just something to think about!
> One of the benefits of optional typing is we can automatically add type annotations from runtime observation.
This has a high coolness factor but is not very sound, because it'll require writing good tests that allow you to make those observations in the first place, right? This is adding to the total test-writing workload of the user, instead of a statically typed language where you just get all of this for "free".
> Mypy supports structural subtyping currently.
I didn't realize this! That's good! Clearly I need to do more research before commenting haha.
This does appear to require an additional external dependency though (the `typing_extensions` module), which is too bad.