[pypy-dev] PyPy progress report
paul.degrandis at gmail.com
Wed Oct 3 20:34:23 CEST 2007
Good news all around! Thanks for sending this out guys.
On 10/3/07, Armin Rigo <arigo at tunes.org> wrote:
> Hi all,
> A quick note to tell you some new things that PyPy can do since the 1.0
> release: more built-in modules, PyPy-on-Java-VMs, and secure sandboxing
> for Python.
> In more details:
> * Threads and weakrefs are now working properly. (There is a GIL -
> global lock - just like in CPython for now.) (As in the 1.0 release,
> you can also have stackless & greenlets instead of threads.)
> * Some missing built-in modules have been written, like zlib.
> The complete list of known-to-be-working built-in modules is:
> _codecs, gc, _weakref, array, marshal, errno,
> math, _sre (regular expressions), operator, symbol, _random,
> _socket, unicodedata, mmap, fcntl, time, select,
> crypt, signal, readline (only readline.readline()),
> termios, zlib, struct, md5, sha
> Of course, all the standard library of Python 2.4, written in Python,
> works out of the box. Also, the following modules have a working pure
> Python implementation in PyPy: binascii, cPickle, cStringIO, cmath,
> collections, datetime, functional, imp, itertools.
> * These two facts together mean that pypy-c can now run some very
> serious programs, like the server for the bub-n-bros game :-)
> I've also successfully used py.execnet for a while.
> * Antonio and Niko are doing some very good work on the Java backend.
> With minor tweaks we can now build a pypy-jvm. FWIW it seems to give
> better performance than Jython. It's not 100% comparable because
> pypy-jvm is not thread-aware or thread-safe yet, while Jython gives
> you free threading; OTOH pypy-jvm doesn't generate Java bytecodes
> on-the-fly (although it might do so in the future). All in all
> pypy-jvm is still experimental, but stay tuned :-)
> * Sandboxing: it is possible to compile a version of pypy-c that runs
> fully "virtualized", i.e. where an external process controls all
> input/output. Such a pypy-c is a secure sandbox: it is safe to run
> any untrusted Python code with it. The Python code cannot see or
> modify any local file except via interaction with the external
> process. It is also impossible to do any other I/O or consume more
> than some amount of RAM or CPU time or real time. This works with no
> OS support at all - just ANSI C code generated in a careful way. It's
> the kind of thing you could embed in a browser plug-in, for example
> (it would be safe even if it wasn't run as a separate process,
> For comparison, trying to plug CPython into a special virtualizing C
> library is not only OS-specific, but unsafe, because one of the known
> ways to segfault CPython could be used by an attacker to trick CPython
> into issuing malicious system calls directly. The C code generated by
> PyPy is not segfaultable, as long as our code generators are correct -
> that's a lower number of lines of code to trust. For the paranoid, in
> this case we also generate systematic run-time checks against buffer
> For more information on this topic please see:
> Armin & cfbolz around
> pypy-dev at codespeak.net
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Pypy-dev