PyPy
PyPy[project-ideas]
modified Mar 28, 2008 by Antonio Cuni

Independent project ideas relating to PyPy

PyPy allows experimentation in many directions -- indeed facilitating experimentation in language implementation was one of the main motivations for the project. This page is meant to collect some ideas of experiments that the core developers have not had time to perform yet and also do not require too much in depth knowledge to get started with.

Feel free to suggest new ideas and discuss them in #pypy on the freenode IRC network or the pypy-dev mailing list (see the home page).


Improve one of the JIT back-ends

  • PyPy's Just-In-Time compiler relies on two assembler backends for actual code generation, one for PowerPC and the other for i386. A good project would be to give the 386 backend a good refactoring, simplifying it, then add support for missing features like floating-point arithmetic. Another idea would be start a new backend for e.g. AMD64 (Intel IA-64) or even a mobile device.
  • Another idea in a similar vein (but requiring some more interaction with the rest of the JIT code) would be to use LLVM to re-compile functions that are executed particularly frequently (LLVM cannot be used for all code generation, since it can only work on a whole function at a time).

CTypes

  • support ctypes on more backends. Right now ctypes is supported only when compiling PyPy to C. A nice project would be to support it when compiling to .NET or the JVM. That's not too hard, the only thing needed is to port a small module that does the actual invocation of external libraries (a related project would be to port this module to Jython or IronPython to get support for ctypes there).

More Interpreter Features

  • support some of the more recent features of CPython. A nice project would be to support all of the remaining Python 2.5 language features.
  • another thing to do on our Python interpreter would be to port over the changes to the standard library (which includes re-writing some of the C-coded modules in RPython or pure Python) that happened in 2.5 or that we are still missing in 2.4.

Experiment with distribution and persistence

One of the advantages of PyPy's implementation is that the Python-level type of an object and its implementation are completely independent. This should allow a much more intuitive interface to, for example, objects that are backed by a persistent store.

The transparent proxy objects are a key step in this direction; now all that remains is to implement the interesting bits :-)

An example project might be to implement functionality akin to the ZODB's Persistent class, without the need for the _p_changed hacks, and in pure Python code (should be relatively easy on top of transparent proxy).

Another example would be to implement a multi-CPU extension that internally uses several processes and uses transparent proxies to share object views.

Improving the automated test framework

Every night, various kinds of PyPy tests run automatically on a variety of different systems. Each set of tests displays its own result on a different web page; for example, here are the results of our unit tests, translation tests and benchmarks and pypy-c compliance tests.

A possible project is to improve our testing infrastructure and build a service that aggregates and displays the results of all the nightly tests.

Various Ideas

  • work on and improve the JavaScript backend
  • improve one of the existing interpreters (e.g. the Prolog, the Scheme or the JavaScript interpreter or the Smalltalk VM)
  • revive the logic object space, which tried to bring unification-like features to Python

Or else...

...or whatever else interests you!

Feel free to mention your interest and discuss these ideas on the pypy-dev mailing list or on the #pypy channel on irc.freenode.net. You can also have a look around our documentation.