Gustavo Carneiro schrieb am 24.06.20 um 19:19:
On Wed, 24 Jun 2020 at 17:22, Victor Stinner wrote:
The question becomes: how to promote the limited C API? Should it become the default, rather than an opt-in option?
It would be interesting to find out what is the performance impact of using limited C API, vs normal API, on some popular extensions. This is something that I wish had been included in PEP 384.
It couldn't because even today it is still fairly difficult to convert existing code to the limited API. Some code cannot even be migrated at all, e.g. because the entire buffer protocol is missing from it. Some bugs were only fixed in Py3.9, time will tell if anything else is missing.
The only major project that I know has been migrated (recently, with a lot of effort) is the PyQt project. And a GUI toolkit probably doesn't have all that many performance critical parts that are dominated by the CPython C-API. (I'm just guessing, it probably has some, somewhere).
It would be great if the limited API could be the default, as it allows building extensions once that work across most python versions.
We are adding a C compile mode for the limited API to Cython. That's also a lot of effort, and probably won't be finished soon, but once that becomes any usable, we'd have a whole bunch of real-world extensions that we could use for benchmarking, many of which were written for speed. We could even take a regular Python module and compile it in both variants to compare "pure Python" to "full C-API" to "limited C-API".