#ty #mypy - but mypy already compiles itself to c via #mypyc so being faster isn't what I'd be expecting, it will be different and probably find different typing errors since for all the type checkers, it comes down to a matter of opinion. Do you think that will be a runtime error? That's in the future, who knows man.
#Mypyc
#cibuildwheel has #python313 (beta) support so it is time to rebuild your native #python libs
https://github.com/pypa/cibuildwheel/releases/tag/v2.20.0
and
https://iscinumpy.dev/post/cibuildwheel-2-19-0/
Here is an example of how I used #cibuildwheel with #mypyc (which in theory can compile to C anything that you can perfectly type annotate)
https://github.com/matthewdeanmartin/untruncate_json/blob/main/cibuildwheel.toml
♡ 1 ↻ 0
So if I take ordinary #python (no math to speak of) and
#cythonize it
#mypyc it
No obvious pattern on if it is faster or not. I don't know where the 20% to 200x rule of thumb came from (that I've seen in various conference talks)
I need to do more experiments but each experiment requires
- three code bases
- two different setup.py, pyproject.toml
- removing things cython/mypyc can't compile (and they differ)
- making a decision about further cython optimizations (taking the code in a direction mypyc can't follow)♡ 0 ↻ 0Running mypyc does pick up more type confusions than mypy alone, although both mypy and mypyc push you to patterns that are compilable/less dynamic.
♡ 0 ↻ 0
I've been trying every x months to speed up #python with native code. This weekend with half-assed effort I got a rust + python thing going.
- c, go, c++, #cython - failed because the difficult level of dealing with the build scripts. And c, c++ are just nasty.
- #mypyc - Almost worked, but failed, the annotations have to be a perfect subset of what mypyc can handle.
Mypyc and cython need something like maturin if they want get widespread adoption.