I would rather we focus on doing well with one type checker and it seems that mypy is significantly more popular than pytype so its more natural for users. I would support pytype if it covered more PEPs and was the newer and upcoming thing but that doesn't seem to be the case.
On Sun, Jan 12, 2020 at 7:48 PM Chad Dombrova <chad...@gmail.com> 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 <eh...@google.com> 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) >> >> >> >>
