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 >
