SPy: An interpreter and compiler for a fast statically typed variant of Python • Hacker News Board

Re: SPy: An interpreter and compiler for a fast statically typed variant of Python

#61

Post by vidarh » Wed, Nov 05, 2025, 3:37 PM UTC

pjmlp wrote: post #21

cardanome wrote: post #18

Common 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?

Just like Smalltalk and SELF, also Lisp Machines and Interlisp-D. Usually comes down from a urban myth that Python is special and there was no other dynamic language before it came to be. The JIT research on those platforms is what gave us leading JIT capabilities on modern runtimes, OpenJDK HotSpot traces back to Smalltalk and StrongTalk, while V8 traces back to SELF. Especially in Smalltalk and SELF, you can change…

> Granted what messes up Python, or better said CPython implemenation, is that C extensions are allowed to mess up with its internals thus making void many possible optimizations that would be otherwise available.

I'm doing a Ruby compiler (very, very slowly, though faster again now with Claude Code doing most of the heavy lifting), and the same issue with Ruby has made me seriously toy with the idea of one day embedding a C compiler so that the Ruby compiler can optimise across both (it'd still have to deal with linking to third party C code, of course, which is one reason I'm hesitating) as a simple not-so-optimizing C compiler is like a trivial toy compared to compiling Ruby where just the parser makes you want to claw your eyes out, but it'd at least widen the surface a bit.

Re: SPy: An interpreter and compiler for a fast statically typed variant of Python

#62

Post by rich_sasha » Wed, Nov 05, 2025, 3:42 PM UTC

adsharma wrote: post #58

++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.

Re: SPy: An interpreter and compiler for a fast statically typed variant of Python

#63

Post by __mharrison__ » Wed, Nov 05, 2025, 3:43 PM UTC

This is really cool and what I thought mojo would be. The subset of Python that is easy to use, read, and removes the dynamic nature that we don't use.

Excited to see where this goes.

Re: SPy: An interpreter and compiler for a fast statically typed variant of Python

#64

Post by ranger_danger » Wed, Nov 05, 2025, 4:00 PM UTC

I'm still looking for a python-ish (at least the syntax) embeddable library for C that is easy to include in a project, a library that does not have its own build system with dozens of files... but I don't think one exists.

Re: SPy: An interpreter and compiler for a fast statically typed variant of Python

#65

Post by dec0dedab0de » Wed, Nov 05, 2025, 4:11 PM UTC

ajb wrote: post #45

It'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…

I would say that Rpython is successful. However, it's primary goal is to be whatever the PyPy developers need to write PyPy.

I totally agree about subsets though, I would much rather have a superset like Cython, but that has it's own challenges for compatibility if you wanted to have a "pure python" version of the same library. Which is why I really like that Cython is using typehints now.

Re: SPy: An interpreter and compiler for a fast statically typed variant of Python

#66

Post by kgeist » Wed, Nov 05, 2025, 4:21 PM UTC

Reminds me of Shed Skin, but no mention of it. I wonder how they compare.

https://en.wikipedia.org/wiki/Shed_Skin

Re: SPy: An interpreter and compiler for a fast statically typed variant of Python

#67

Post by ajb » Wed, Nov 05, 2025, 5:02 PM UTC

dec0dedab0de wrote: post #65

ajb wrote: post #45

It'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…

I would say that Rpython is successful. However, it's primary goal is to be whatever the PyPy developers need to write PyPy. I totally agree about subsets though, I would much rather have a superset like Cython, but that has it's own challenges for compatibility if you wanted to have a "pure python" version of the same library. Which is why I really like that Cython is using typehints now.

Yeah Rpython escapes this as most people don't write it directly.

Micropython is another example. No-one expects micropython to support numpy. They're just happy to get away from C. But where you can use the full python, you wouldn't use micropython.

Re: SPy: An interpreter and compiler for a fast statically typed variant of Python

#68

Post by summarity » Wed, Nov 05, 2025, 5:04 PM UTC

Imustaskforhelp wrote: post #15

summarity wrote: post #8

Earlier quoted context omitted.

You can have that today with Nim.

Nim feels like a really amazing language. There were some minor things that I wanted to do with it. Like trying to solve a codeforces question just out of mere curiosity to build something on top of it. I felt like although it was similar to python. You can't underestimate the python's standard library features which I felt lacking. I am not sure if these were skill issues. Yes these are similar languages but I would…

GPT is amazing at Nim. Ive used it to find a subtle bug in a macro that’s hundreds of lines of code.

Re: SPy: An interpreter and compiler for a fast statically typed variant of Python

#69

Post by jszymborski » Wed, Nov 05, 2025, 5:17 PM UTC

While obviously this would need CPython to SPy `import` support for it to displace CPython for me, it seems like you can `import` SPy to CPython, which makes it an attractive solution for implementing fast libraries where Rust is perhaps too heavy duty.

Re: SPy: An interpreter and compiler for a fast statically typed variant of Python

#70

Post by PaulHoule » Wed, Nov 05, 2025, 5:27 PM UTC

ajb wrote: post #45

It'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…

One of the standard architectures for complex applications is to put together a scripting language and an systems programming language. You can either look at the scripting language as primary with the systems language used for performance or hardware interfacing or you can look at the systems language being primary and the scripting being used around the edges.

The model of having a closely related scripting and systems language would be an optimization of this and SPy seems like an answer.

[1] AAA games that have a scripting engine on top of C/C++, a finite element solver that lets you set up a problem with Lua and solve it with FORTRAN, etc.