+1 The typing information has really helped me several times figuring out that API contracts and expected types.
On Mon, Mar 2, 2020 at 9:54 AM Pablo Estrada <pabl...@google.com> wrote: > I am in favor of enabling the test, and also am happy to start answering > questions too. > Thanks so much Chad for leading this. > Best > -P. > > On Mon, Mar 2, 2020 at 9:44 AM Chad Dombrova <chad...@gmail.com> wrote: > >> Good news everyone! >> We nearly have the full beam codebase passing in mypy. >> >> As we are now approaching the zero-error event horizon, I'd like to open >> up a discussion around enabling mypy in the PythonLint job. Every day or >> so a PR is merged that introduces some new mypy errors, so enabling this >> test is the only way I see to keep the annotations accurate and thus useful. >> >> Developer fatigue is a real concern here, since static typing has a a >> steep learning curve, and there are still not a lot of experts to help >> consult on PRs. Here are some things that I hope will mitigate those >> concerns: >> >> - We have a lot of tying coverage, so that means plenty of examples >> of how to solve different types of problems >> - Running mypy only takes 10 seconds to complete (if you execute it >> outside of gradle / tox), and that will get better when we get to 0 >> errors. Also, running mypy in daemon mode should speed that up even more >> - I have a PR[1] to allow developers to easily (and optionally) setup >> yapf to run in a local git pre-commit hook; I'd like to do the same for >> mypy. >> - I will make myself and members of my team available to help out >> with typing questions in PRs >> >> Is there anyone else on the list who is knowledgable about python static >> typing who would like to volunteer to be flagged on typing questions? >> >> What else can we do to make this transition easier? >> >> [1] https://github.com/apache/beam/pull/10810 >> >> -chad >> >>
