[pypy-dev] Extended goals (was: needed 18 month plan of what we would do in developing PyPy if we got funding.)

Armin Rigo arigo at tunes.org
Fri Sep 12 13:15:07 CEST 2003


First, thanks to Christian for starting this thread -- I guess PyPy
applications could make another group of workpackages at least as big as the
"core PyPy" workpackages I listed in plan.txt.

On Thu, Sep 11, 2003 at 03:20:25PM +0200, Samuele Pedroni wrote:
> one thing I think we should not forget is that merit of Python success is 
> also because it is a good glue language. While PyPy performance change the 
> balance of the equation, I think it will still be very important.

Samuele has a point here. We should consider some of the major application
areas of today's Python (glue language, scientific/numeric, Zope) and argue
what PyPy can offer in addition to CPython. In general it's all based on 
flexibility; for example:

> 2) well he can embed PyPy in his code, PyPy extension mechanism and 
> taylorability make
> that easy and the overhead for PyPy to C++ calls very low, some PyPy 
> classes can also work as C++ subclasses (<- this two thing is something we 
> would have to work on, extending what is already there for CPython and 
> beyond)

Here was can target C++ for the translation, representing Python objects as
classes which could be tailored to be compatible with the existing
application's class model.

More generally, we can put forward as a goal the reduction of the boilerplate
interfacing code. This boilerplate isn't so huge right now, which is in part
why Python is good as being a glue language, but still it is large enough that
there are specific tools like SWIG to help generate it. We can help there,
both to reduce the amount of code and to actually reduce the corresponding
run-time overhead.

For numeric applications, there are several senarios that come to mind, based
on Christian's and Holger's messages. However I don't know Numeric well enough
to see what could really be done, so take this with a grain of salt. We could
rewrite Numeric in RPython and regenerate good come from that, which has the
advantage that the code can indeed be very good because it can be tailored to
use (or not) particular hardware features. So far it can more or less be done
with a C library full of #defines. The difference is in its integration: this
Numeric can influence PyPy's own object layout and alignment if needed, for
example. It can also be translated into something that checks at run-time for
what features are present; in C it is harder to do without recompilation. But
more importantly, if it is written in RPython instead of C it can be subjected
to other transformations like Psyco-ification, the net result of which would
be a Psyco that knows about Numeric types and can directly generate
processor-optimized code like SSE2.

A bientot,


More information about the Pypy-dev mailing list