Standardization Recommendation: Use Function annotations for method arguments and return types

See this excellent SO response for an idea on what this is and where it is helpful: https://stackoverflow.com/a/21384492/54818

You can see how folks like @hamelsmu use them here: https://github.com/hamelsmu/code_search/blob/master/notebooks/general_utils.py

While they don’t throw exceptions if you pass in the wrong type, they’re nice because of the implicit in-line documentation they provide the user. You know exactly what the method wants and what is going to be returned without having to read through the documentation.

Thoughts?

2 Likes

I would love to have fully statically type checked python code, using mypy (‘http://mypy-lang.org’). It seems to get more and more traction.

ps. by ‘…read through the documentation…’ you probably meant ‘read through the source code’ :slight_smile:

1 Like

Actually, I think I meant a little of both. It’s nice to not have to search the docstring to know what values you can and cannot assign to method arguments and also what to expect to get when the method returns.

And yah, mypy is getting a lot of traction.

Yup we’ll be doing this :slight_smile:

1 Like

Any update on mypy integration? I’ve seen a number of cases where the type annotations in the codebase are incorrect. In some of these cases, PyCharm is smart enough to highlight the errors for me. Here is an example:

def transform(self, tfms:Optional[Tuple[TfmList,TfmList]]=(None,None), **kwargs):

Here is another one:

def get_transforms(do_flip:bool=True, flip_vert:bool=False, max_rotate:float=10., max_zoom:float=1.1,
                   max_lighting:float=0.2, max_warp:float=0.2, p_affine:float=0.75,
                   p_lighting:float=0.75, xtra_tfms:Optional[Collection[Transform]]=None)->Collection[Transform]: