"Having a Python C module gives significantly more power and performance, but comes with costs. it requires more code, it’s harder to find good documentation; and few features are easily accessible. While C modules appear to be an under-utilized tool for writing high performance Python modules (based on some FunctionTrace profiles I’ve seen), we’d recommend a balance. Write most of the non-performance critical code in Python and call into inner loops or setup code in C, for the pieces where Python doesn’t shine."

I've been wondering recently about the maintainability/community aspect of C vs. pure-python packages. I was choosing between a pure-python simhash library and 5-times-as-fast library with a C++ core, and ultimately had to choose pure-python because the C++ one doesn't have recent releases, can't be reliably installed from source, and is harder for me to fix if it breaks. In other words it suffers from a lower bus facter, which I'd predict is generally true of Python packages with a fast non-Python core.

This got me wondering, what is the way to write a fast core for a Python package that is most ... likely to survive, I guess, once the original maintainer loses interest? Would it be some form of C (I think necessary in this case), Rust (once the tooling gels a little), lua, wasm, something else?