Yes, that's why the work has to start ASAP. There is currently a project to abstract the C-API with HPy: https://speakerdeck.com/antocuni/hpy-a-future-proof-wa

Yes, that's why the work has to start ASAP. There is currently a project to abstract the C-API with HPy: https://speakerdeck.com/antocuni/hpy-a-future-proof-way-of-extending-python https://speakerdeck.com/antocuni/hpy-a-future-proof-way-of-e... The idea is to (very slowly) remove access to direct CPython internals and give a handle to important low-level behavior through a standardized API hidding implementation details. It's a lot of work, and going to affect a huge part of the ecosystem, but I'm hopeful this is something the extensions authors will actually want to be part of because it promises to solve a lot of problems: - on the long run, this will make maintaining a c-extension much easier: more stability no matter the evolution of upstream, more certainty. - there will be a clear way to do things, which means better documentation and conventions, potentially libs to do common things. Right now creating extensions is more a set of receipes people found out to work. - because of this, scrutiny will be given to common patterns, which will be abstracted and optimized, and given the security of an API contract - extensions using this API will work out of the box, or faster if they already did, on alternative python implementations like pypy Of course, the end goal is to free the python core devs to experiment with breaking changes at the c level, such as changing the memory management model, and eventually maybe remove the GIL or allow for a JIT.