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