[pypy-dev] missing things for making PyPy "production" ready (for some value of production)

[Jean-Paul Calderone]

On Wed, 14 Nov 2007 17:16:48 +0100, Carl Friedrich Bolz <cfbolz at gmx.de> wrote:
>Hi all,
>
>I thought I would start a new thread for discussing what PyPy needs to
>become "production ready" (whatever that is) and succeed as a Python
>implementation. This is something were outside opinions are very welcome
>(of course there is no guarantee we can implement all of your wishes :-)
>).
>
>Obvious problems are:
>  - some missing extension modules of the stdlib. no clue which of them
>    are really important, depends on the application you want to run, I
>    guess. This can be worked on by outsiders.
>

I tried running a piece of real-world software the other day, an IRC bot
which I use regularly in a number of channels, using pypy-c with boehm gc.

I had to disable imports of the pwd and syslog module and add an early
return to a function which would have otherwise called setuid and setgid
from the os module, since none of these things are available on pypy.  I
filed tickets in the issue tracker for these three things.

After I did that, the bot was able to start up and connect to a network,
join channels and provide basic functionality.

>  - lack of 3rd-party extension-module support. This is hard to change.
>    Once we implement ctypes the problem will be mitigated, but not
>    solved: it's no fun at all to wrap a large C++ library with ctypes,
>    and there are lot's of existing non-ctypes based modules out there.

Some of the functionality of the bot is unavailable on PyPy, since it relies
on the third-party PyCrypto extension module.

>
>  - Speed. The JIT is still not in a state where it really speeds up
>    arbitrary Python code. I expect this to change sooner or later.
>    However, it's not an area were a lot of people can help.

The bot was slightly sluggish on PyPy, as compared to on CPython.  This
was mostly noticable at startup and shutdown.  Network latency probably
greatly overshadowed any performance difference responding to events from
the IRC server.  Overall, for this application, PyPy is fast enough.

>
>  - for PyPy-JVM: bindings to allow the interaction with arbitrary Java
>    libraries, threading support
>

Humm.  Nothing to say to this. :)

Jean-Paul