> > > 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 -chad
