The biggest thing PyPy adds is JIT compilation. This is precisely what the project to add JIT to CPython is working on these days. It's still early days for the project, but by 3.15 there's a good chance we'll see some really great speedups in some cases.
It's worth noting that PyPy devs are in the loop, and their insights so far have been invaluable.
> That said, I wonder if GIL-less Python will one day enable GIL-less C FFI? That would be a big win that Python needs.
I'm pretty sure that is what freethreading is today? That is why it can't be enabled by default AFAIK, as several C FFI libs haven't gone "GIL-less" yet.
Can you clarify the concern? Starting from C I've come to expect many dialects across many compiler implementations. It seems healthy and encourages experimentation. Is it not a sign of a health language ecosystem?
It's a culture thing. C culture is all about rolling your own bespoke solution, which encourages the formation of dialects. On the other hand, Python culture is all about "There should be one-- and preferably only one --obvious way to do it.": https://peps.python.org/pep-0020/#the-zen-of-python
Well, they added an experimental JIT so that is one step closer to PyPy? Though would assume the trajectory is build a new JIT vs. merge in PyPy, but hopefully people learned a lot from PyPy.
You write the ffi once and let hundreds or thousands of other developers use it. For one off executables it rarely make sense.
Mixing the use with other libraries provided by the Python ecosystem is a another scenario. Do you really want to do HTTP in C or do you prefer requests?
These days you could probably build a pretty performant numpy like using shared memory with Arrow format and IPC for control.
Though it would be considerably more complex and not at all easier than FFI...
That said, I wonder if GIL-less Python will one day enable GIL-less C FFI? That would be a big win that Python needs.