I&#x27;m not sure I appreciate that criticism of Cython. A general strategy in Cython is to use the annotation feature (cython -a) and visually inspect the degree of CPython API necessary for the lines of Cython source code. I&#x27;ve generally found this process to be really enlightening. Of course you can use that information to select portions of the code that don&#x27;t need to be involving the CPython API, add typed contructs to those parts of the Cython source, and iterate. But you can also learn a lot about how CPython works ... for example how using the &#x27;and&#x27; keyword can invoke a long chain of Python special functions with lots of type checking overhead.<p>What this lets me do is to be extremely fine-grained about my optimizations, or conversely, to also see when some optimizations are not worth it because they don&#x27;t help much but they do hurt the readability, or cause too much Python-to-Cython divergence as you put it.<p>In a lot of cases, I prefer that this is left up to me to do, rather than if Cython had already made hand-mapped choices about which Python things compile to which C or machine code things. If taken to the limit, a Cython that did that would just become what PyPy is, except it would be ahead of time compiled instead of JIT compiled.<p>But I do see the benefit of both approaches. Sometimes you don&#x27;t want the burden of choosing your annotations to induce the desired compilation effect, and you don&#x27;t want to allow for similar but not identical Cython source files to result in dramatically different C code, as can often happen currently.