Hi folks, I agree with Robert that we need to wait and see before making any decisions, but I do have some opinions about the probable/desired outcome.
I haven't used pytype, but my experience working with mypy over the past few years -- and following various issues and peps related to it and typing in general -- has taught me there's still a lot of room for interpretation and thus variation between type checkers. Here's a simple example: ignoring errors. Both tools support ignoring errors using a `type: ignore` comment, but only mypy (to my knowledge) supports specifying an error type so that only that error is suppressed, e.g. `type: ignore[error-code-here]`. There's even room for differences with regard to the line number where the error is emitted and thus where the ignore comment must be placed (end of statement, site of open paren, site of close paren, etc). I know this because mypy has actually made adjustments to this once or twice over the years, which necessitated moving existing ignore comments. So just imagine having to ignore the same error separately for each type checker. It's not the end of the world, but it's ugly and frustrating. As a user, it can be quite challenging to solve certain typing issues, and there's a fairly steep learning curve – I wouldn't want to burden users with *two* type checker, each with its own idiosyncrasies. That said, a linter that doesn't actually prevent merges when an error occurs will be ignored by users and quickly become less-than-useful. Post-commit would not be a good idea for all the reasons that a post-commit lint check would be annoying (user's will trip it often and feel surprised/blind-sided). In the little exposure that I've had with pytype it seems to lag behind mypy in terms of features, especially wrt typing-related peps (it never fully supported pep484 multi-line type comments and it still doesn't support pep561, I see no mention of pep589/TypedDict in the docs, but then again they are *incredibly* light). I've gotten mypy completely passing, and I know it very well, so I'm pretty biased towards making it the one and only type checker that generates pre-commit errors. I see little advantage to most end users in supporting pytype, except y'know, Google has kind of an important presence in Apache Beam project :) Some quick pypi download figures to back that up: Downloads last month: pytype: 24,864 mypy: 1,502,582 So to sum up this email in a sentence: running mypy in pre-commit checks would be beneficial, but making pytype also pass would be a burden with little benefit for the majority of users. But as I said at the outset, before we make any decisions we should get at least one type checker in place and start getting feedback, because we're still in the land of conjecture. Hopefully I'll have all my typing changes merged in the next month or two, at which point we can discuss enabling it as part of the pre-commit lint job. -chad On Tue, Jan 7, 2020 at 7:02 PM Udi Meiri <[email protected]> wrote: > Hi, > We recently added mypy to the Jenkins Lint job for PRs (currently ignores > errors). Mypy is a static type checker. > > There's a JIRA for adding another static type checker named pytype > https://issues.apache.org/jira/browse/BEAM-9064 > > I wanted to ask the community their thoughts on this. (see JIRA issue > comments as well) > > - Should PRs have to pass more than 1 static type checker? (in pre-commit > tests) > - If not, should the remaining type checkers be run as a post-commit tests? > - How much effort should be put into supporting more than 1 type checker? > (i.e. making sure that they all pass) > > > >
