Hacker News new | ask | show | jobs
by rnestler 368 days ago
I tested it quickly on a 30kLOC project. zmypy seems to be faster than mypy indeed:

Without mypy cache:

  $ rm -rf .mypy_cache
  $ time mypy
  Success: no issues found in 157 source files
  mypy  20.40s user 2.33s system 108% cpu 20.886 total
With mypy cache without any changes:

  $ mypy --version
  mypy 1.16.0 (compiled: yes)
  $ time mypy
  Success: no issues found in 157 source files
  mypy  0.56s user 1.84s system 628% cpu 0.381 total
mypy with a small change in a shared module

  $ time mypy
  Success: no issues found in 157 source files
  mypy tests/  2.32s user 2.06s system 168% cpu 2.601 total
zmypy:

  $ time zmypy
  Found 68 errors in 16 files (checked 157 source files)
  zmypy  0.68s user 0.05s system 99% cpu 0.731 total

Without caching and parallelization (as the 99% CPU usage indicates) it comes in the range of mypy using the cache and multiple cores (628% CPU usage) without any changes in the code.

zmypy seems to find more errors but they mostly boil down to the following errors

* Call to untyped function "__setitem__" in typed context

* ... has incompatible type "MagicMock"; expected ...

Maybe __setitem__ and MagicMock are treated specially in mypy? Also there seem to be differences in handling Protocol and enum comparison.

1 comments

The MagicMock case is indeed interesting. I am not sure what Mypy does there, I would have to investigate. The other issues are probably bugs and should be reported to https://github.com/zubanls/zubanls/issues if you are interested in fixes.