The feels like JS -> TS type of change on JS side, except that was done with transpiler (sp ? ).
SPy: An interpreter and compiler for a fast statically typed variant of Python
71–80 of 133 posts
Re: SPy: An interpreter and compiler for a fast statically typed variant of Python
#72It's weird, but the pain of moving to a whole new language seems less than the pain of using one of these language subsets. I guess it might be because of "loss aversion": we dislike losing something we have more the value we put on gaining it. In a new language each newly added feature is a gain, but in a language subset you're always encountering things you would have in the full language. So no matter how good the…
Throwing my hands up and moving to Nim was downright easy next to the excessive effort I put into trying out Nuitka, Numba, and PyInstaller for my use case. If you want static compilation, use a language and libraries built with that assumption as a ground rule. The herculean effort of building a half-compatible compiler for a dynamic language seems like a fool's errand, and would be a fun curiosity if so many people…
It's so common for something like this to struggle for decades before succeeding.
For instance people have been trying to make a memory safe C for a long time, just recently we got
which has high compatibility and relatively good performance for that kind of thing. The strength of Python is that so many people are trying things with it.
Re: SPy: An interpreter and compiler for a fast statically typed variant of Python
#73Statically typed. That's just Java with python syntax again, which the article tries to talk it's way out of but that's what it is.
Re: SPy: An interpreter and compiler for a fast statically typed variant of Python
#74Common Lisp also allows you to redefine everything at runtime but doesn't suffer from the same performance issues that Python has, does it? Doe anyone have insight into this?
Common Lisp doesn't use (expensive) CLOS dispatch in the core language, e.g. to add two numbers or find the right equality operator. That's one known pain point due to CLOS having been "bolted-on" rather than part of the language which makes the divide between internal (using typecase and similar) and external (generic functions) dispatch pretty ugly; and gave use the eql/equal/equalp/etc... hell. Thing is that you n…
> Thing is that you need a complex JIT like Julia's or stuff like https://github.com/marcoheisig/fast-generic-functions to offset the cost of constant dynamic dispatch.
Julia is always the odd one out, when talking about dynamic vs. static dispatch, because its JIT compiler acts more like an Ahead-of-Time compiler in many regards.
In the best case, types are statically decidable and Julia's compiler just produces a static dispatch and native code like e.g. a C compiler would.
In the worst case, there are a big (or unlimited) number of type candidates.
The grey area in between, where there are a limited number of type candidates, is interesting. As far as I understand, Julia does something similar to the link you provided. Based on some heuristics it will compile instances for a "sealed" number of candidates and fallback to a fully dynamic dispatch, if there are two many type candidates.
At JuliaCon 2025 there was an interesting talk about this topic: https://m.youtube.com/watch?v=iuq534UDvR4&list=PLP8iPy9hna6S...
For the worst case scenario, Julia chooses what's in my regard the nuclear option: If the types are not decidable, it just ships the whole compiler with your code and tries again at runtime. But I guess, that's not the only possible solution. Presumably, it would also be possible to fallback to a Julia interpreter for dynamic code. That would be more similar to what JavaScript is doing, just the other way around. Instead of interpreting the majority if the code and optimising hot paths with a JIT, our alternative Julia would compile most code statically and use the interpreter for the dynamic parts.
Re: SPy: An interpreter and compiler for a fast statically typed variant of Python
#75If in the end we can just have .spy on some files that have performance critical functions in them and the rest is just normal python, this could be down right amazing.
We recently swapped out mypyc optimised module for a rust implementation to get a 2-6x speed up, and not having to do that would be great.
Re: SPy: An interpreter and compiler for a fast statically typed variant of Python
#76It's weird, but the pain of moving to a whole new language seems less than the pain of using one of these language subsets. I guess it might be because of "loss aversion": we dislike losing something we have more the value we put on gaining it. In a new language each newly added feature is a gain, but in a language subset you're always encountering things you would have in the full language. So no matter how good the…
Throwing my hands up and moving to Nim was downright easy next to the excessive effort I put into trying out Nuitka, Numba, and PyInstaller for my use case. If you want static compilation, use a language and libraries built with that assumption as a ground rule. The herculean effort of building a half-compatible compiler for a dynamic language seems like a fool's errand, and would be a fun curiosity if so many people…
all of this is well and good if you completely forget that there are billions of lines of Python in prod right now. so your grand epiphany is basically on the level of "let's rewrite it in Rust". i'll let you hold your breath until that rewrite is done (and in the meantime i'll explore workarounds).
Re: SPy: An interpreter and compiler for a fast statically typed variant of Python
#77++spy ethos and ideas But why limit to an interpreter? Translate to other excellent compiled languages and benefit from the optimization work there. Giving up on C-API and the dynamic parts of python that 1% of the people use is a good trade-off. In the age of cursor and windsurf it's not hard to auto replace incompatible code with something that works in the static-py ecosystem. Would love to participate in an effor…
There is a compiler detailed in the page on the link; > 3. We have a compiler for deployment and performance. The interpreter and the compiler are guaranteed to produce the exact same results at runtime.
Where is it? Would love to compare the approach to py2many.
Re: SPy: An interpreter and compiler for a fast statically typed variant of Python
#78++spy ethos and ideas But why limit to an interpreter? Translate to other excellent compiled languages and benefit from the optimization work there. Giving up on C-API and the dynamic parts of python that 1% of the people use is a good trade-off. In the age of cursor and windsurf it's not hard to auto replace incompatible code with something that works in the static-py ecosystem. Would love to participate in an effor…
I'd imagine a lot of packages that you may want to use make deep use of some of these obscure features. So much magical "it just works" of Django is surely various kinds of deep introspection. Not sure an AI can fix it yet. It's not just adding type annotations.
The position I take is that such obscure code in the guts of a popular package could be slowing down large amounts of deployed code elsewhere. If such code must exist, it should be marked as special (like how Cython does it).
Beyond adding type annotations, there are other important problems to solve when translating python to rust (the most popular path in py2many so far).
* Translating inheritance -> traits
* Translating exceptions -> Result
* Handling incompatible pattern matching
Re: SPy: An interpreter and compiler for a fast statically typed variant of Python
#79It's weird, but the pain of moving to a whole new language seems less than the pain of using one of these language subsets. I guess it might be because of "loss aversion": we dislike losing something we have more the value we put on gaining it. In a new language each newly added feature is a gain, but in a language subset you're always encountering things you would have in the full language. So no matter how good the…
Throwing my hands up and moving to Nim was downright easy next to the excessive effort I put into trying out Nuitka, Numba, and PyInstaller for my use case. If you want static compilation, use a language and libraries built with that assumption as a ground rule. The herculean effort of building a half-compatible compiler for a dynamic language seems like a fool's errand, and would be a fun curiosity if so many people…
I was looking for someone else that had done this, I had the same exact experience.
That said, anyone looking into a completely static typed language that has nice ergonomics, is easy to pick up but has enough depth to keep you busy for weeks on end, and is versatile enough to be used for anything, do yourself a favor and give Nim a try.
Re: SPy: An interpreter and compiler for a fast statically typed variant of Python
#80Earlier quoted context omitted.
Throwing my hands up and moving to Nim was downright easy next to the excessive effort I put into trying out Nuitka, Numba, and PyInstaller for my use case. If you want static compilation, use a language and libraries built with that assumption as a ground rule. The herculean effort of building a half-compatible compiler for a dynamic language seems like a fool's errand, and would be a fun curiosity if so many people…
all of this is well and good if you completely forget that there are billions of lines of Python in prod right now. so your grand epiphany is basically on the level of "let's rewrite it in Rust". i'll let you hold your breath until that rewrite is done (and in the meantime i'll explore workarounds).
I kind of object to this take.
Nobody's talking about porting billions of lines of code, for all we know it's just for personal projects, or a learning experience.
This kind of replies is like killing an idea before it's even started, smells like the sunk cost fallacy.
OTOH I do understand the weight of a currently existing corpus in production, evidence is the ton of COBOL code still running. But still, your reply kind of sucks.