4 ms·

Regarding Python C extension compatibility ... A number of projects (e.g. this bcrypt package -- https://pypi.python.org/pypi/bcrypt https://pypi.python.org/py

Regarding Python C extension compatibility ... A number of projects (e.g. this bcrypt package -- https://pypi.python.org/pypi/bcrypt https://pypi.python.org/pypi/bcrypt) have switched from using CPython's API for C extensions, and switched to the cffi package (https://pypi.python.org/pypi/cffi https://pypi.python.org/pypi/cffi), giving them what seems to be a much cleaner (and less CPython-specific) break between the C-level and the Python-level code. I say "seems to be" because I'm not too familiar with the internals to know for sure :) What cffi did give them is that bcrypt (with it's C component) can be used by both CPython and PyPy -- even though PyPy doesn't support any of CPython's native C API. Meaning that PyPy just has to support cffi, and is otherwise freed from any fixed C interface itself. I think the reason cffi gives it this freedom is that cffi provides Python-side metadata about the C datastructures being worked with through cffi, allowing the PyPy JIT to efficiently integrate that information into it's compilation process.

yoklov 12y ago
My guess is that this would still be a bottleneck in practice. LuaJit has a similar feature, and Mike Pall has said several times that if you care about performance, you're almost certainly better off using 100% Lua, because calling into C is slow. Though, it seems much easier to work around for the implementation than the existing Python C API.
- justincormack 12y ago
  With LuaJIT calling C from the ffi is fast (from jitted code), just the traditional Lua C interface is slow. Lua code can be faster as it can optimise through the boundary of course.