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...