1. 69
  1.  

  2. 18

    This resembles my experience in adding types to existing projects: you almost always find a few a couple of real bugs. The other thing is that typechecking speeds up development: mypy is usually quicker to run than the testsuite so you waste less time before finding out you’ve made a silly mistake.

    1. 4

      I wholeheartedly agree, however, the type errors can be dizzying for programmers who aren’t software engineers. I work with data scientists & product managers who contribute Python code, and adding mypy types had some negative effects to their ability to contribute. Overall, I think we came out ahead; I’m thankful for mypy. I’d love to see better error messages.

      1. 5

        Yeah, this is somewhere where I think most type checkers/compilers leave a ton of value on the table – tracking down a bug caught by a type error is usually much easier than than one caught by a test suite (or in prod…), because it points you to the source of the error rather than the eventual consequences of not catching it. But then many type checkers do a poor job of explaining the error, which undermines this. Elm deserves mention for doing a particularly good job here.

        1. 3

          I would rather teach data scientists who use Python about how to use type annotations than forego using them in Python programs just in case a data scientist needs to touch that code.

          1. 2

            I work on pytype, and we do try to improve the error messages where we can (e.g. here’s a recent commit improving “primitive types ‘str’ and ‘int’ aren’t comparable” to “primitive types ‘x: str’ and ‘10: int’ aren’t comparable”), however when you’re down in the weeds of developing a type checker it can often be hard to notice an error message is not readily comprehensible or helpful. I would encourage you to file a bug with mypy whenever you find an error message hard to read.

        2. 6

          I rediscover the importance of strong typing every time I switch from Swift to Python.

          1. 2

            I am actually finding it difficult to figure out from this post which errors were caught by using MyPy as opposed to simply reviewing the code (I am looking for bugs caught because of the better typing.). I found one. Were there any others?

            1. 6

              surely there are more subtle ones, like these:

              keep in mind that urllib3 is a very mature, well-tested library. this is not true to the same extent for many other projects. strict type hinting prevents many subtle bugs, even with good test coverage, especially when callers (accidentally) deviate from ‘intended’ usage.

              on top of that, tools that check code means reviews become easier, and the same applies to refactoring, which means it becomes easier to keep a code base maintainable over time.

              1. 3

                keep in mind that urllib3 is a very mature, well-tested library. this is not true to the same extent for many other projects. strict type hinting prevents many subtle bugs, even with good test coverage, especially when callers (accidentally) deviate from ‘intended’ usage.

                I think the question isn’t “did adding Mypy prevent bugs”, but did it prevent enough bugs to justify the investment? He did say that “Adding type hints to urllib3 was clearly a huge amount of work, hundreds of engineer hours across several month”.

                1. 8

                  i am convinced it does, especially if you consider the wider ecosystem.

                  downstream consumers benefit massively from this. applications with subtle bugs triggering only in production (even with okay test coverage) cost a tremendous amount of engineering work (and overhead). preventing these right at the moment the mistake was introduced (this can literally be seconds after typing the code!) is a huge win.

                  on top of that it simplifies code reviews for urllib3 itself, prevents regressions, doubles as documentation etc.

                  1. 1

                    somewhere on pytype’s infinite todo list is better support for inferring and then automatically adding type hints to a codebase. we had that functionality at one point, but no one really used it (possibly because inference wasn’t as good back then), so it’s unmaintained and needs an overhaul.