# pypy / pypy / doc / how-to-contribute.rst

 Maciej Fijalkows… 75c166d 2013-03-30 Maciej Fijalkows… 106a992 2013-04-11 Maciej Fijalkows… 75c166d 2013-03-30 Maciej Fijalkows… cd4858f 2013-05-17 Maciej Fijalkows… 75c166d 2013-03-30 Armin Rigo 2f71b39 2013-06-17 Markus Unterwadi… ccc1d50 2013-07-01  1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 How to contribute to PyPy ------------------------- This page describes how to contribute to the PyPy project. The first thing to remember is that PyPy project is very different than most projects out there. It's also different from a classic compiler project, so academic courses about compilers often don't apply or lead in the wrong direction. Don't just hack --------------- The first and most important rule how not to contribute to PyPy is "just hacking". This won't work. There are two major reasons why not -- build times are large and PyPy has very thick layer separation which make it harder to "just hack a feature". Test driven development ----------------------- Instead, we practice a lot of test driven development. This is partly because of very high quality requirements for compilers and partly because there is simply no other way to get around such complex project, that will keep you sane. There are probably people out there who are smart enough not to need it, we're not one of those. You may consider familiarizing yourself with pytest_, since this is a tool we use for tests. This leads to the next issue: Layers ------ PyPy has layers. Just like Ogres or onions. Those layers help us keep the respective parts separated enough to be worked on independently and make the complexity manageable. This is, again, just a sanity requirement for such a complex project. For example writing a new optimization for the JIT usually does **not** involve touching a Python interpreter at all or the JIT assembler backend or the garbage collector. Instead it requires writing small tests in rpython/jit/metainterp/optimizeopt/test/test_* and fixing files there. After that, you can just compile PyPy and things should just work. The short list of layers for further reading. For each of those layers, a good entry point is a test subdirectory in respective directories. It usually describes (better or worse) the interfaces between the submodules. For the pypy subdirectory, most tests are small snippets of python programs that check for correctness (calls AppTestXxx) that will call the appropriate part of the interpreter. For the rpython directory, most tests are small RPython interpreters that perform certain tasks. To see how they translate to low-level graphs, run them with --view. To see small interpreters with a JIT compiler, use --viewloops option. * **python interpreter** - it's the part implemented in the pypy/ directory. It's implemented in RPython, which is a high level static language with classes, garbage collection, just-in-time compiler generation and the ability to call C. A cool part about it is that it can be run untranslated, so all the tests are runnable without translating PyPy. **interpreter** contains the interpreter core **objspace** contains implementations of various objects exported to the Python layer **module** directory contains extension modules written in RPython * **rpython compiler** that resides in rpython/annotator and rpython/rtyper directories. Consult introduction to RPython_ for further reading * **JIT generator** lives in rpython/jit directory. optimizations live in rpython/jit/metainterp/optimizeopt, the main JIT in rpython/jit/metainterp (runtime part) and rpython/jit/codewriter (translation-time part). Backends live in rpython/jit/backend. * **garbage collection** lives in rpython/memory The rest of directories serve specific niche goal and are unlikely a good entry point. .. _introduction to RPython: getting-started-dev.html .. _pytest: http://pytest.org/ 
Tip: Filter by directory path e.g. /media app.js to search for public/media/app.js.
Tip: Use camelCasing e.g. ProjME to search for ProjectModifiedEvent.java.
Tip: Filter by extension type e.g. /repo .js to search for all .js files in the /repo directory.
Tip: Separate your search with spaces e.g. /ssh pom.xml to search for src/ssh/pom.xml.
Tip: Use ↑ and ↓ arrow keys to navigate and return to view the file.
Tip: You can also navigate files with Ctrl+j (next) and Ctrl+k (previous) and view the file with Ctrl+o.
Tip: You can also navigate files with Alt+j (next) and Alt+k (previous) and view the file with Alt+o.