[pypy-dev] practical experiences with PyPy's extension compiler
Martijn Faassen
faassen at infrae.com
Wed Aug 23 12:51:15 CEST 2006
Hey,
As someone who suggested to Brian he try something like this with PyPy,
I just wanted to highlight this. To make sure the PyPy developer's
brains don't turn off when they hear Zope, that's not important bit, so
I changed the title. :) Please all read Brian's entry!
Brian Sutherland wrote:
[snip]
> At EuroPython I investigated re-implementing a class from
> zope.interface in PyPy's Restricted Python. I compiled it to C
> and then compared it to the Pure Python implementation and
> handcrafted C optimization.
>
> Not having touched PyPy before, I found it extremely interesting. The
> report and code I wrote is available here for anyone else interested:
> http://lentejasverdes.ath.cx/stuff/pypy/europython_2006/README.html
The point of Brian's experiment from PyPy's perspective is that you get
feedback on PyPy's utility from a developer who is not primarily engaged
with the development of programming language technology. I think that's
good for the PyPy project.
I think the following strategy has a lot of potential getting PyPy
technology to the "masses":
* write your module in RPython.
* use (R)CTypes if you want to bind to existing C libraries.
* promise performance as this module can compile to a CPython C extension.
* promise maintainability and testability as this module should be able
to run in straight Python (+ CTypes). This is one of the main areas
where this strategy would give practical benefits over technology like
Pyrex.
* and actually all these people are making their extension modules ready
for PyPy too.
I know that this is your strategy, I'm just repeating it to let the echo
sink in. And feedback on the experience from people like Brian may give
vital information on how to improve the experience... In this case,
Brian's feedback (also personally on irc) indicates to me that the above
points have not yet been reached entirely:
* writing RPython is rather difficult as you need to keep the various
levels straight. This unfortunately hurts the maintainability point.
* in this case, the promised performance wasn't delivered, unfortunately.
* as far as I understood it, in this case, the code wasn't directly
testable in CPython after the rewriting to RPython was done. This hurts
the testability case.
(my apologies of any of this is wrong; Brian would know better of course)
I'm really excited about the potential here, so I hope this can be the
start of a longer dialog between PyPy developers and application developers.
Now I'm done highlighting this. :)
Regards,
Martijn
More information about the Pypy-dev
mailing list