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.

I appreciate the personal note:

> Some of you may wonder why ZubanLS isn’t open source, unlike Jedi. The honest answer is that open source never worked out for me financially. Beyond some small donations and a small recurring compensation from Tidelift, I was never able to make a living from it. I'm no longer a student, and with a family to support, it became clear I needed a sustainable path.

> Joining a company like Astral (makers of Ruff) could have been an option—but I’ve also grown skeptical of venture capital as a model. VC-backed companies often need to aim for massive success or risk disappearing within a decade. I want to build something that lasts. I’ve already spent more than ten years in this space, and I plan to continue.

https://zubanls.com/blog/release/

Best of luck!

This is cool! I think the loc-based licensing is smart. Did you consider making the source available under the commercial license terms to support supply chain visibility?