Honestly that seems Sisyphean to me. The market doesn't want a "performant subset". The market is very well served by performant languages. The market wants Python's expressivity. The market wants duck typing and runtime-inspectable type hierarchies and mutable syntax and decorators. It loves it. It's why Python is successful.
My feeling is that numba has exactly the right tactic here. Don't try to subset python from on high, give developers the tools[1] so that they can limit themselves to the fast subset, for the code they actually want. And let them make the call.
(The one thing numba completely fails on though is that it insists on using its own 150+MB build of LLVM, so it's not nearly as cleanly deployable as you'd hope. Come on folks, if you use the system libc you should be prepared to use the system toolchain.)
[1] Simple ones, even. I mean, to first approximation you just put "@jit" on the stuff you want fast and make sure it sticks to a single numeric type and numpy arrays instead of python data structures, and you're done.
PyPy isn't unloved, just incompatible. The routine experience with PyPy is that you try your toy benchmark, drop your jaw in amazement, then run your whole app and it fails. Usually it's because you have a upstream dependency on a native module without a PyPy port, or with an incompatible implementation (I've personally run into trouble with ctypes code that didn't quite work the same in PyPy).
But there are a non-trivial number of genuine behavioral differences too. A big delta is garbage collection. CPython is refcounted and greedy, you can write a loop doing more-than-just-heap allocation (like, opening files or something), and it works fine because objects get destroyed (closed) as they're no longer used. The same loop in PyPy runs into resource exhaustion because the relevant resource (file descriptors) runs out before the heap does and the GC doesn't run.
The community has tried to address this particular glitch with cryptic admonishments about using "with" that no one quite understands or can explain, but it hasn't taken and it remains true that PyPy basically doesn't work for anything big unless you develop in PyPy. And honestly I don't see a lot of attention to the issue, it's like PyPy doesn't think it has to be 100% compatible to win. Well, it does.
But getting back to my upthread poing: numba doesn't have those properties. Numba is just CPython, with the added feature that when you know you need a fast loop for something you write your python code to look like C and put a @jit decorator on it.
> The market wants duck typing and runtime-inspectable type hierarchies and mutable syntax and decorators. It loves it.
These features have one thing in common: they're only useful for prototype-quality throwaway code, if at all. Once your needs shift to an increased focus on production use and maintainability, they become serious warts. It's not just about performance (though it's obviously a factor too), there's real reasons why most languages don't do this.
The existence of several type-checkers and Astral's largely-successful efforts to build tooling that pulls Python out of its muck seems to suggest otherwise.
Better things are possible, and I'm hoping that higher average quality of Python code is one of those things.
> That assumes python is one monolithic thing and everyone agrees what it is.
It's exactly the opposite! I'm saying that python is BIG AND DIVERSE and that attempts like SPy to invent a new (monolithic!) subset language that everyone should use instead are doomed, because it won't meet the needs of all the yahoos out there doing weird stuff the SPy authors didn't think was important.
It's fine to have "differing ideas on what python is", but if those ideas don't match those of all of the community, and not just what you think are the good parts, it's not really about what "python" is, is it?
My feeling is that numba has exactly the right tactic here. Don't try to subset python from on high, give developers the tools[1] so that they can limit themselves to the fast subset, for the code they actually want. And let them make the call.
(The one thing numba completely fails on though is that it insists on using its own 150+MB build of LLVM, so it's not nearly as cleanly deployable as you'd hope. Come on folks, if you use the system libc you should be prepared to use the system toolchain.)
[1] Simple ones, even. I mean, to first approximation you just put "@jit" on the stuff you want fast and make sure it sticks to a single numeric type and numpy arrays instead of python data structures, and you're done.