On Mon, Jan 13, 2020 at 6:43 PM Chad Dombrova <[email protected]> wrote:
> > I agree with focusing one mypy for now, but I would propose soon after, >> or in parallel if it will be different folks, to work on pytype and enable >> it as a first class citizen similar to mypy. If there will be a large delta >> between the two then we can decide on what to do next. >> >> If there is a large delta, I wonder if what is needed to provide >> sufficient typing on the public API of beam (needed for users) could >> be a much smaller subset than that required fully >> documenting/typechecking the internals (which is also likely to be >> where more of the tricky bits are). >> > > Let's separate our two use cases for type checking: > > 1) developers working on the Beam source > 2) developers using Beam > > For #1, there's little to gain from running a second type checker, and as > discussed, it's a burden. so mypy is the clear winner here. > > For #2, there's actually no need to expose all of the internals of Beam to > pytype, and as Robert points out, this is where the "tricky bits" reside. > We could use mpy's stubgen tool to create .pyi files of just the API > interface -- no internals -- as a separate apache_beam_stubs package. Then > pytype users (or users of other type checkers) could optionally install > this and point pytype at it. This would be a bit more automatic for end > users if pytype supported pep561[1], which is all about the packaging and > discovery of typed packages, including stub-only packages like I'm > proposing. > > https://github.com/google/pytype/issues/151 > This proposal sounds reasonable to me. Udi, would it be possible to share this thread with pytype developers or invite them to comment here. It would be good if they can take Beam as a use case and see the feedback shared here. > > > -chad > >
