It's not only what we believe in, but also that PyPy's architecture is
working very well with TDD in mind and not so well without it. Often
the development means progressing in an unrelated corner, one unittest
- at a time and then flipping a giant switch. It's worth repeating - PyPy
+ at a time; and then flipping a giant switch, bringing it all together.
+ (It generally works out of the box. If it doesn't, then we didn't
+ write enough unit tests.) It's worth repeating - PyPy
approach is great if you do TDD, not so great otherwise.
* PyPy uses an entirely different set of tools - most of them included
-PyPy has layers. The 100 mile view:
+PyPy has layers. The 100 mile view:
-* `RPython`_ is a language in which we write interpreter in PyPy. Not the entire
- PyPy project is written in RPython, only parts that are compiled in
+* `RPython`_ is the language in which we write interpreters. Not the entire
+ PyPy project is written in RPython, only the parts that are compiled in
the translation process. The interesting point is that RPython has no parser,
it's compiled from the live python objects, which make it possible to do
all kinds of metaprogramming during import time. In short, Python is a meta
programming language for RPython.
RPython standard library is to be found in ``rlib`` subdirectory.
+ RPython standard library is to be found in ``rlib`` subdirectory.
.. _`RPython`: coding-guide.html#RPython
-* Translation toolchain - this is the part that takes care about translating
- RPython to flow graphs and then to C. There is more in `architecture`_
+* The translation toolchain - this is the part that takes care about translating
+ RPython to flow graphs and then to C. There is more in the `architecture`_
document written about it.
It mostly lives in ``rpython``, ``annotator`` and ``objspace/flow``.