On Mon, Jan 13, 2020 at 5:34 PM Chad Dombrova <chad...@gmail.com> wrote: >> >> Pytype seems to detect attribute errors that mypy has not, so it acts as a >> kind-of linter in this case. >> Examples: >> https://github.com/apache/beam/pull/10528/files#diff-0cb34b4622b0b7d7256d28b1ee1d52fc >> https://github.com/apache/beam/pull/10528/files#diff-7e4ad8c086414399957cdbea711ebd36 >> https://github.com/apache/beam/pull/10528/files#diff-d5c3f4f603204c5c5917d89e90dba53d >> (it also makes pytype more strict in a sense) > > Note that mypy is still not fully passing on master so it's unclear from > those diffs exactly how the two tools differ. Many of the fixes you've made > for pytype look familiar to me from mypy, but my fixes may not be merged yet. > For example, mypy also does not support @total_ordering, but my fix for that > is still pending.
As it seems we have a workaround to ignore pytype for now, it seems to make the most sense to focus on getting mypy working completely before focusing on that. In the long term, we could look into making pytype a post-commit which would at least be a useful signal for those caring about it, and only make it a precommit if the diff between what it requires and mypy requires is quite small.
