Wow, that is an incredible amount of work! I'm definitely of the opinion that there's no viable counterargument to the value of types, especially for large or complex codebases.
This kind of check must be in precommit or it will become perma-red very quickly. Kenn On Mon, Oct 28, 2019 at 4:21 PM Valentyn Tymofieiev <valen...@google.com> wrote: > Thanks a lot, Chad. Looking at the PR, I am incredibly happy to see > explicit type annotations throughout Beam codebase. I believe this is a > step in the right direction even if the tooling were not able to do any > inference at all. The effort required from developers to add annotations in > their code changes will be well compensated by reducing cognitive load > required to read the codebase, and will lower the entry barrier for new > contributions. Lack of docstrings in Beam internals in Beam codebase, > especially the lack of typing information, has repeatedly come up as a > source of frustration among several folks with whom I work. > > As Beam devs will be gaining more first-hand experience with the tooling, > we may need to add a style guide/best practices/FAQ to our contributor > guide to clarify known issues. > > Happy to help with reviewing individual commits once we have a merge plan > in place. > > On Mon, Oct 28, 2019 at 2:41 PM Robert Bradshaw <rober...@google.com> > wrote: > >> Thanks, Chad, this has been a herculean task. I'm excited for the >> additional tooling and documentation explicit types can bring to our >> code, even if tooling such as mypy isn't able to do as much inference >> for obvious cases as I would like. >> >> This will, of course, put another burden on developers in contributing >> code, similar to lint and writing unit tests. IMHO this will be worth >> the cost in terms of encouraging better code, but I think it's >> important to establish consensus if this is the direction we're >> moving. So if you have any thoughts or questions, positive or >> negative, please comment. >> >> >> On Mon, Oct 28, 2019 at 10:34 AM Chad Dombrova <chad...@gmail.com> wrote: >> > >> > Hi all, >> > I've been working on a PR to add static typing to the beam python sdk >> for the past 4 months or so. This has been an epic journey which has >> required chasing down numerous fixes across several other projects (mypy, >> pylint, python-future), but the mypy tests are now passing! >> > >> > I'm not sure how much convincing I need to do with this group on the >> benefits of static typing, especially considering the heavy Java influence >> on this project, but for those who are curious, there's some good info >> here: https://realpython.com/python-type-checking/#pros-and-cons. >> Suffice it to say, it's a game changer for projects like Beam (large code >> base, high level of quality, good testing infrastructure), and it dovetails >> perfectly into the efforts surrounding pipeline type analysis and >> serialization. Anecdotally speaking, all of the developers I've worked >> with who were originally resistant to static typing in python ("it's >> ugly!" "it's not pythonic!") have changed their tune and fully embraced it >> because of the time that it saves them every day. >> > >> > More details over at the PR: https://github.com/apache/beam/pull/9056 >> > >> > I look forward to your feedback! >> > >> > -chad >> > >> >
