Udi, what would we gain by using pytype? Also, has anyone tried running pytype against Beam? If it's not too much trouble, it might be helpful to diff the pytype and mypy results to get a feel for exactly how big the discrepancy is.
On Mon, Jan 13, 2020 at 3:26 PM Kenneth Knowles <[email protected]> wrote: > Looking at this from the outside, it seems like mypy is the obvious > choice. Also running pytype could potentially be informative in some cases > but only if there is a specific gap. What about maintenance/governance of > the two projects? > > Kenn > > On Sun, Jan 12, 2020 at 7:48 PM Chad Dombrova <[email protected]> wrote: > >> 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) >>> >>> >>> >>>
