Comment by didip
5 days ago
Every time I hear news about Python language itself, it sadden me that, in 2025, PyPy is still a separate distinct track from mainline Python.
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.
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?
What do you mean exactly? C FFI has always been able to release the GIL manually.
> 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?
Pypy compatibility with cpython seems very minor in comparison https://pypy.org/compat.html
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.
There is some information transfer happening. Antonio Cuni was at the latest Coython developer sprint and shared some insights from PyPy https://antocuni.eu/2025/09/24/tracing-jits-in-the-real-worl...
How do you see that changing?
Python introduce another breaking change than also randomly affects performance, making it worse for large classes of users?
Why would the Python organisers want to do that?
I don't understand why C FFI is that popular.
The amount of time it takes spent to write all the cffi stuff is the same amount it takes to write an executable in C and call it from python.
The only time cffi is useful is if you want to have that code be dynamic, which is a very niche use case.
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?
Could you go into more detail? How would you build e.g. numpy without FFI?
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...
We need the FFI to share memory in-process with C functions?
[flagged]
Guido stepped down over 7 years ago. How out of touch are you?
Who are you talking about? Python hasn't had a dictator for ages now.
He's right in everything else though.