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.
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.
It's worth noting that PyPy devs are in the loop, and their insights so far have been invaluable.
What do you mean exactly? C FFI has always been able to release the GIL manually.
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.
Pypy compatibility with cpython seems very minor in comparison https://pypy.org/compat.html
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?
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.
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?