4 ms·

> Yes, you can use type hints and an external type checker, but that's still not a great solution compared to any statically styped language. Why not?

DonaldPShimoda 7y ago
Well it isn't built-in, so that's an obstacle to its use right there. 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. Furthermore, the static type systems supported by, e.g., MyPy do not perfectly reflect the dynamic semantics of the Python language. So what you really have is some subset of Python that you're allowed to use fully. (This is probably not a big issue for many people, to be fair.) 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 most common complaints about Java is that you have to write so many types everywhere, and while you don't need that many in statically typing your Python code, you do need quite a few. A statically typed language with good type inference definitely wins here. Type hints are also not very expressive because they're purely nominal, but Python's type system is actually structural (which is true for most dynamically typed languages, as far as I know). I haven't experimented with this too much because I don't use a type checker like MyPy, but I seem to remember that it treated types nominally. (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.) What I'm getting at here is that while external type checkers like MyPy can be considered an improvement over the dynamically typed language itself, they come with a lot of caveats that make me uncomfortable. There are few cases where I truly prefer dynamic types to static ones.
- j88439h84 7y ago
  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
  > 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. As I have grown as a developer I have shifted from favoring dynamic fly-by-the-seat-of-your-pants typing to static explicit typing, even with the added verbosity[1] because... writing `int` takes a moment, but typing based bugs last a lifetime. Strict typing is worth the extra code overhead as it can drastically reduce code maintenance costs when coupled with a good architectural design. That said, I still hate hate haaaaate java-doc style dressed up comments and out of band enforcement in general - I want a first party tool to verify my typing and for that typing to be confirmed at run time or compile time depending on the language style (interpreted vs. compiled). If typing isn't correctly used everything should break. On that topic, I've been loving PHP's move toward explicit typing since PHP7. 1. I still don't like C++ (pre C++11 which was the last I used... so auto may change my thoughts if I get a chance to play with it industrially) because the verbosity was super excessive.

DonaldPShimoda 7y ago

Well it isn't built-in, so that's an obstacle to its use right there. 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. Furthermore, the static type systems supported by, e.g., MyPy do not perfectly reflect the dynamic semantics of the Python language. So what you really have is some subset of Python that you're allowed to use fully. (This is probably not a big issue for many people, to be fair.) 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 most common complaints about Java is that you have to write so many types everywhere, and while you don't need that many in statically typing your Python code, you do need quite a few. A statically typed language with good type inference definitely wins here. Type hints are also not very expressive because they're purely nominal, but Python's type system is actually structural (which is true for most dynamically typed languages, as far as I know). I haven't experimented with this too much because I don't use a type checker like MyPy, but I seem to remember that it treated types nominally. (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.) What I'm getting at here is that while external type checkers like MyPy can be considered an improvement over the dynamically typed language itself, they come with a lot of caveats that make me uncomfortable. There are few cases where I truly prefer dynamic types to static ones.

j88439h84 7y ago
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
> 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. As I have grown as a developer I have shifted from favoring dynamic fly-by-the-seat-of-your-pants typing to static explicit typing, even with the added verbosity[1] because... writing `int` takes a moment, but typing based bugs last a lifetime. Strict typing is worth the extra code overhead as it can drastically reduce code maintenance costs when coupled with a good architectural design. That said, I still hate hate haaaaate java-doc style dressed up comments and out of band enforcement in general - I want a first party tool to verify my typing and for that typing to be confirmed at run time or compile time depending on the language style (interpreted vs. compiled). If typing isn't correctly used everything should break. On that topic, I've been loving PHP's move toward explicit typing since PHP7. 1. I still don't like C++ (pre C++11 which was the last I used... so auto may change my thoughts if I get a chance to play with it industrially) because the verbosity was super excessive.