4 ms·

Thanks for elaborating, that's all interesting. > Well it isn't built-in, so that's an obstacle to its use right there. Yeah, no doubt. > You also have to re

Thanks for elaborating, that's all interesting. > Well it isn't built-in, so that's an obstacle to its use right there. Yeah, no doubt. > You also have to rely on two sets of developers to ensure you can stay up-to-date, and this introduces more potential for errors and bugs. [Edit: Some of] The maintainers of mypy are python core developers, so it's not quite two sets of developers. :-) > Another problem is that systems like MyPy require you to actually write the type hints in a lot of places. Manifest type systems are not favored because requiring users to write more is almost never something they're happy with. One of the benefits of optional typing is we can automatically add type annotations from runtime observation. Then we get the documentation benefits of typing without the work of writing them. https://monkeytype.readthedocs.io https://monkeytype.readthedocs.io is a good tool for this. > (I think I've also seen some indication that they're working to extend type hints to support structural types, but last I checked it wasn't right around the corner or anything.) Mypy supports structural subtyping currently. It's extremely useful. https://mypy.readthedocs.io/en/latest/protocols.html https://mypy.readthedocs.io/en/latest/protocols.html

DonaldPShimoda 7y ago
> Yeah, no doubt. (re: two tools) 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.
- j88439h84 7y ago
  [Edited: some of the Mypy maintainers, e.g. Guido van Rossum and Ivan Levkivskyi are on the Python core team, not all of them.] > 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". Yeah it does require executing the code. Python has a strong test-coverage culture. Do people not run tests much in more-static languages? > This does appear to require an additional external dependency though `typing.Protocol` is in Python 3.8.
  - yawaramin 7y ago
    > 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.
    - munk-a 7y ago
      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.
  - DonaldPShimoda 7y ago
    > some of the Mypy maintainers Ah, fair enough. Still, I hadn't realized that! > 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.

DonaldPShimoda 7y ago

> Yeah, no doubt. (re: two tools) 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.

j88439h84 7y ago
[Edited: some of the Mypy maintainers, e.g. Guido van Rossum and Ivan Levkivskyi are on the Python core team, not all of them.] > 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". Yeah it does require executing the code. Python has a strong test-coverage culture. Do people not run tests much in more-static languages? > This does appear to require an additional external dependency though `typing.Protocol` is in Python 3.8.
- yawaramin 7y ago
  > 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.
  - munk-a 7y ago
    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.
- DonaldPShimoda 7y ago
  > some of the Mypy maintainers Ah, fair enough. Still, I hadn't realized that! > 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.