1. 18

  2. 6

    Clearly a lot of work went into this post, but I found it less of a “state of type hints” and more of a “what and how”, in that I was expecting an overview of adoption, or progress in the type system. Having said that, it’s probably an excellent post for someone wondering “what are type hints in Python and how can I use them?”

    However, I’m pretty sure the final paragraph is incorrect?

    Remember that, similar to unit tests, while it does makes your code base contain an extra number of lines, at the end of the day all the code you add is code that is automatically checked and enforced to be correct. It acts as a safety net to ensure that when you change things around later on things keep working

    In a statically-typed language this would be true, but type hints in Python are just hints. There’s no guarantee from Python that either the hints or what’s passed is actually correct.

    1. 7

      While it’s true that Python’s type-hints aren’t automatically enforced, the same is true of tests: they don’t help either unless you run the test suite. At least for Python, comparing types and tests in this way seems reasonable.

      1. 3

        In a statically-typed language this would be true, but type hints in Python are just hints.

        I write a lot of Python and thus far I’ve eschewed type hints, for the simple reason that if I’m gonna go to all that effort I might as well just write Go.

        (I’m being slightly sarcastic, but there’s a kernel of truth in there.)

        1. 6

          I also write a lot of Python, and I type-hint 100% of it. The type hints typically take very little effort to write, and the benefits (IDE help + fewer bugs + easier refactoring) save me a lot of work, so on net it’s almost certainly effort-saving.

          (A bonus that’s possibly orthogonal to effort is that having to think about and write out the types I use encourages me to design cleaner APIs and makes a lot of bad code smells much more obvious.)

          1. 2

            Sure, and Python will still support that. Now imagine you’re an organization like Google and you have 100 million lines of Python in your company’s repo. It’s not going to be economically viable to rewrite it but you’d still like to incrementally add type checking to try to lower the rate bugs are found in Python code. That’s where Python’s type checking makes sense at the moment. I’ve still yet to see much adoption in the scientific Python space, for example, although I bet that’s mostly because NumPy doesn’t have type stubs yet.

            1. 3

              If wishes were fishes, one of the fish in my river would be to have something like [Elm’s record types], but for specifying Pandas data frame column names instead of record fields. Elm’s record types do not require you to specify all of the input’s fields; instead, you specify the ones the function expects, and the fields that are guaranteed to be in the output. The typechecker keeps track of which fields a record has as it passes through the functions.

              It would be perfect for the domain-specific cleaning and wrangling functions one writes on top of pandas. I realise this is not a trivial thing to wish for, though.