except it's work. and it's not that good usually because you end up manipulating Python objects anyway. It doesn't really work for anything that can't be represented as a tight semi-autonomous C code with limited connection to Python code. And then you usually can't run it on PyPy, which might or might not be an issue.

Yes, that is the trade-off, but I think you'll definitely be able to find areas where you can use c to do some processing in the bottlenecks. If you find you don't have enough performance, it is an area to explore. My experience is with ruby and rubyinline, granted ruby isn't as fast as Pypy.

Unless that work was already done and available to you (lxml).

See comments on the blog. Majority of work is not in xml parsing so lxml does not help (and you're crippled that the rest of the code does not run as fast).

In the same way C implementation could be interesting. The purpose was measure efficient of PyPy for you Python code.