Expanded usage of type hinting and checking

[ntouran]

We've learned through the years (as many Python users have) that one major disadvantage of Python is the lack of static typing. This leads to runtime errors that a type checking system would have found at compile time. Fortunately, a bunch of big companies have made type checking pre-processors, like mypy.

We have slowly been putting some type hints in the framework. I'm making this a discussion rather than a ticket because one big ticket about typing would probably be too big of a scope.

• Can we implement meaningful type checking progressively (e.g. as we add type hints here and there)?

If so,

• where should we prioritize?
• Do we have a preferred type checker?
• Let's make the github action to typecheck

[jakehader]

Hey @ntouran, the MonkeyType package might be useful to try and add type annotations to the codebase - https://pypi.org/project/MonkeyType/ (solution from https://stackoverflow.com/a/50416746).

I haven't tried it yet, but it might be easy to process only module at a time and then go through and update docstrings accordingly for smaller PRs. I might take a stab at this over the holidays.

[john-science]

This is a fun idea. Maybe I'll give it a whirl today and see how it goes.

[john-science]

MonkeyType is pretty easy to use! I'll open a little example PR and share.

[john-science]

@ntouran

• Where should we prioritize?
  • Only the API of the code (public attributes/methods) needs type-checking. I suppose it doesn't hurt on private stuff, but it is 200% more useful on public members. Now WHERE in the API to start, is a fine question. I'm not sure.
• Do we have a preferred type checker?
  • mypy, probably
• Let's make the GitHub action to type check
  • That's an interesting idea. I haven't seen that one yet. That sounds doable.

I imagine type hinting will be easier to implement than type checking. And we will definitely want to relegate type checking to unit tests or builds only. We don't want to slow down the runtime by doing type checking during a run.

[jakehader]

I think that we should prioritize public methods and start with type hinting. We should probably try out type checking in certain applications and see what the performance would be. I found this article to be pretty good - https://dropbox.tech/application/our-journey-to-type-checking-4-million-lines-of-python.

Also, beartype (https://pythonrepo.com/repo/beartype-beartype-python-code-analysis-and-linter#how-much-does-all-this-cost) might be interesting to check out too as an alternate to mypy

[john-science]

Okay, after playing with monkeytype, the system is definitely not perfect. I thought it would automate the process and making adding typing trivial. But Python type hinting can be quite tricky for custom classes in situations where you are cross-importing across modules as much as we do.

I think monkeytype is a great place to start. But even so, fully type hinting our code base would not be super easy.

However, improving the type hinting to get, say, 80% code coverage might be fairly easy. Perhaps the question is where to start. I might suggest something like these:

• Interface
• Operator
• RunLog
• Plugin
• Reactor
• Component
• Material
• Setting / Settings
• EntryPoint

[jakehader]

That sounds good to me. I didn't think any package would work 100% straight out of the gate, but giving us a head start in type hinting is great! Did you say you were going to put a PR together to demo it?

[john-science]

I have opened an example PR of adding type hinting using monkeytype: #531

I described the strengths and weaknesses of the process there.

TLDR; Nothing will fully automate our type hinting.

Idea: We should probably request people add type hints to all new, public methods in future ARMI PRs.