PyPy allows experimentation in many directions. This page is meant to collect some ideas of things to try. If you are a student you can also get inspired for a proposal for our new Summer of PyPy campaign: you get a mentor and good funding of travel and accomodation for our sprints.
Feel free to suggest new ideas and discuss them on IRC or the pypy-dev list (see the contact page).
Rewrite one or several CPython extension modules to be based on ctypes (newly integrated in Python 2.5): this is generally useful for Python developers, and it is now the best path to write extension modules that are compatible with both CPython and PyPy. This is done with the extension compiler component of PyPy, which will likely require some attention as well.
Modules where some work is already done:
You are free to pick any other CPython module, either standard or third-party (if relatively well-known). Note that some modules exist in a ctypes version already, which would be a good start for porting them to PyPy's extension compiler. We'd particularly appreciate readline :-)
At the EuroPython sprint, some work was done on making RPython's annotator recognise Numeric arrays, with the goal of allowing programs using them to be efficiently translated. It would be a reasonably sized project to finish this work, i.e. allow RPython programs to use some Numeric facilities. Additionally, these facilities could be exposed to applications interpreted by the translated PyPy interpreter.
PyPy has complete, or nearly so, back-ends for C, LLVM and CLI/.NET and partial backends for Common Lisp and Squeak. It would be an interesting project to improve either of these partial backends, or start one for another platform -- the most obvious of which would be the Java Virtual Machine.
Write an interpreter for another dynamic language in the PyPy framework. For example, a Javascript interpreter would be suitable. Ruby too (though the latter is probably more than two months of work). Or Scheme, or... etc.
We have a prototype Prolog interpreter :-)
A research project: experiment with optimizations in PyPy, e.g. by trying various data structures for dicts or other built-in objects, by switching between data structures at run-time, comparing results for different applications, etc. This should produce experimental results (mostly timings, memory usage trade-offs) as much as code. (The point of PyPy is that we can do this without making the interpreted applications aware of the optimization at all.)
For example, we have started some work on:
Revive rexec: implement security checks, sandboxing, or some similar model within PyPy (which, if I may venture an opinion, makes more sense and is more robust than trying to do it in CPython).
There are multiple approaches that can be discussed and tried. One of them is about safely executing limited snippets of untrusted RPython code (see http://codespeak.net/pipermail/pypy-dev/2006q2/003131.html). More general approaches, to execute general but untrusted Python code on top of PyPy, require more design. The object space model of PyPy would easily allow objects to be tagged and tracked. The translation of PyPy would also be a good place to insert e.g. systematic checks around all system calls.
Write new object spaces adding features like transparent or semi-transparent distribution of a program across several machines, and/or persistence (pickling of program state). This could typically be based on "proxy" objects, behaving as transparent links to objects located on other machines. Read more about object spaces...
...or whatever else interests you!
Note: currently it is a bit difficult for us to identify nice independent sub-tasks in the context of the JIT compiler of PyPy...
Feel free to mention your interest and discuss these ideas on the pypy-dev mailing list. You can also have a look around our documentation.