I'm thinking of Mapscript bindings that allows to interact with Mapserver. They generate biding for several languages through Swig.
Some projects uses Swig precisely because of that characteristic. Project with "low bandwidth" for whom maintaining different binding generator for every language they support would be painful.
In my case, I could probably hack a minimal cffi binding. But solving the problem at the root would be a better solution for everyone.
Swig already use some form of cffi for Common Lisp apparently so maybe python-cffi support could be derived from that. I don't know for sure, just thinking out loud.
The problem with SWIG is that current SWIG bindings would not be reusable. Any major project using SWIG for Python already has a bit of glue and this glue tends to be CPython C API. SWIG has other modes, but it has not been the case in the past.
Sure, but still, having a way within SWIG to generate both standard python binding and more cffi-friendly python could help transitioning.
That way, new projects can still benefit from the strength of SWIG that allows them to propose bindings for multiple languages with a single tool. Because, let's not kid ourselves, using specific binding libs for every single language you want to support has a cost. And in that case backward compatibility does not matter much.
All the while giving a transition path for projects still using what I would call the legacy way. Or those who want/need to poke in the CPython API.
I haven't used SWIG in 15 years, but having it emit a cffi shim would be a great way to get existing projects ported over to a more portable interface without requiring them to change anything.
Some projects uses Swig precisely because of that characteristic. Project with "low bandwidth" for whom maintaining different binding generator for every language they support would be painful.
In my case, I could probably hack a minimal cffi binding. But solving the problem at the root would be a better solution for everyone.
Swig already use some form of cffi for Common Lisp apparently so maybe python-cffi support could be derived from that. I don't know for sure, just thinking out loud.