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.
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.
> 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.
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?
I'm definitely not qualified to offer an informed opinion on a specific license, but there are a variety to choose from under the general heading of Source-available Licenses. There are definitely tradeoffs so it may not make sense for you, but it might open up some portion of the market that might not consider a black box.
Without mypy cache:
With mypy cache without any changes: mypy with a small change in a shared module zmypy: 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.