Hacker News Reader

Comment by vore | Hacker News Reader

In a larger codebase, there's two major kinds of value you can get out of types:

- Types act as a contract between component surfaces - if you need to integrate multiple components and have different people working on it, having the compiler enforce the contract is super useful.

- Types act as a refactoring aid - if you need to alter a component, the compiler can assist you in telling you what needs to be changed and you can offload more of that work at compile time rather than at run time.

As pieces move and change, tracking down what else needs to get moved and changed gets more and more difficult and this is where the "passing the wrong type in" issue can occur: having the compiler help you out with that is a huge boon.

View on HN

Similar to your first point, types also allow an IDE to inform user about what values can be used for a function or class argument.

I can't say that typing bugs occurred very often in released code I wrote before type annotations, but it was not uncommon to encounter them when testing code I had just written (where they usually just caused an exception early on in the program's lifecycle).

If it were a compiled language where I had to wait to run it, I could see that being a big help, but in python I just constantly run the parts of the code I'm editing. If there are any typing issues I catch them almost immediately.

To be fair, I do set return types in my docstrings, and let the IDE help there.

My gripe really stems from using a libraries that check for a type and raise an exception if it doesn't match. Instead of just trying to actually use it and see if that fails. for example If you require a dict because you're going to expect certain keys, but I have a class that has __get_item__ for those keys, it should work fine. If you check the type then you'll fail before you get that far.

Imagine you need to change the type that's passed to a function. You attempt to update all places, but you miss a path that's in an edge case.

Static typing would have caught that for you. By waiting until runtime, you've now just potentially shipped a regression.

As a code base gets large, it's just not possible/practical to run all possible ways the code you're editing can be reached. Unless you happen to be lucky enough to have 100% unit test coverage, which very few people do, and running that test suite is somehow quick enough to be a practical alternative to static typing.

If I need to change a type thats passed to a function that already exists and is heavily used, I would either cast the old type to the new type so both work, or create a new function. If I really cared about cleaning it up I would add a deprecation warning when its done the old way.

For doing "duck-typing" formally, you need Interfaces or Protocols, rather than checking from a shortlist of allowed types.

Here's a blog post [1] from this discussion on Django 3.2 [2] 10 days ago.

[1] https://glyph.twistedmatrix.com/2021/03/interfaces-and-proto...

[2] https://news.ycombinator.com/item?id=26710013

Actually, this precursor blog post focusing on typing.Protocols is even clearer:

https://glyph.twistedmatrix.com/2020/07/new-duck.html

Reply on news.ycombinator.com