[HN Gopher] Using Mypy in Production
       ___________________________________________________________________
        
       Using Mypy in Production
        
       Author : charliermarsh
       Score  : 23 points
       Date   : 2022-08-22 20:31 UTC (2 hours ago)
        
 (HTM) web link (notes.crmarsh.com)
 (TXT) w3m dump (notes.crmarsh.com)
        
       | kungfufrog wrote:
       | I can't articulate specifically why but using typing in Python
       | just feels like so much pain compared to other languages that
       | have "opt-in" nominal typing syntax (PHP et al.).
       | 
       | The workflow feels frustrating, the ecosystem seems diverse and
       | has no clear "blessed" path, and I'm still confused about what is
       | bundled by Python and what I need to pull in from an external
       | source. I REALLY want to use mypy but by the time I've figured
       | out how to pull it all together I probably could have finished
       | the program I'm working on.
       | 
       | The relevant factor here might be the size of Python programs I
       | typically work on, somewhere between a few hundred lines and a
       | few thousand.
       | 
       | I'm glad other people are having success because hopefully
       | that'll smooth the pavement for the next time I circle around and
       | try to add some meaningful types to my Python programs.
        
       | codekansas wrote:
       | 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...
        
       ___________________________________________________________________
       (page generated 2022-08-22 23:00 UTC)