Comment by codekansas

As someone who owns multiple label makers and organizes my utensils by type when I put them into the dishwasher I really like Mypy. Cool writeup, good points. I think a lot of people (ML scientist people especially) who haven't been forced to use a type checker don't realize the productivity benefits of having a type checker running on your whole codebase - they only see the annoying slow-down of having to do things a particular way and having the type checker bug you for inconspicuous errors.

Example: One pattern (which I don't think a lot of people are familiar with?) that I started adopting recently is the use of `Literal` for type-checking strings. For example, instead of something like

(on closer reading I realized this was in the blog post as well, but I suspect maybe some ML people will have seen this specific case before)

  class ActivationType(enum.Enum):
    sigmoid = "sigmoid"
    tanh = "tanh"

  def get_activation(key: str | ActivationType) -> nn.Module:
    key = ActivationType[key]
    if key == ActivationType.sigmoid:
      return nn.Sigmoid()
    if key == ActivationType.tanh:
      return nn.Tanh()
    raise KeyError(key)

you can do something like this instead:

  from typing import Literal

  ActivationType = Literal["sigmoid", "tanh"]

  def get_activation(key: ActivationType) -> nn.Module:
    if key == "sigmoid":
      return nn.Sigmoid()
    if key == "tanh":
      return nn.Tanh()
    raise KeyError(key)

The advantage is that you can do something like

  act = get_activation("tahn")

and Mypy will show an error for your typo (instead of having to run your code and eventually hit the `KeyError`). So if you're just trying to quickly implement an idea, you don't have to kill brain cells searching for typos.

Of course, doesn't make a difference if your coworkers all use Vim and Emacs with no extensions...