[pypy-svn] rev 2601 - pypy/trunk/doc/overview

[alex at codespeak.net]

Author: alex
Date: Fri Dec 19 18:49:27 2003
New Revision: 2601

Added:
   pypy/trunk/doc/overview/architecture.txt
      - copied, changed from rev 2598, pypy/trunk/doc/overview/architecture
Log:
renamed, and more material at the end


Copied: pypy/trunk/doc/overview/architecture.txt (from rev 2598, pypy/trunk/doc/overview/architecture)
==============================================================================
--- pypy/trunk/doc/overview/architecture	(original)
+++ pypy/trunk/doc/overview/architecture.txt	Fri Dec 19 18:49:27 2003
@@ -93,10 +93,30 @@
 used to implement the interpreter and object space) and *application
 level* (Python that we are interpreting).  To show the difference with
 an example: to sum the contents of two variables ``a`` and ``b``, typical
-application-level code is ``a+b`` -- in constrast, typical
+application-level code is ``a+b`` -- in sharp contrast, typical
 interpreter-level code is ``space.add(w_a, w_b)``, where ``space`` is an
 instance of the standard object space class and ``w_a`` and ``w_b`` are
-typical names for the *wrapped* versions of the two variables.
+typical names for the *wrapped* versions of the two variables.  By
+contrast, think of traditional CPython: it has the same
+application-level code, but interpreter-level code is C source, and
+typical code for the addition would be ``PyNumber_Add(p_a, p_b)``
+where ``p_a`` and ``p_b`` are C variables of type ``PyObject*``.
+
+You might think that the need to keep the two roles for the same
+language distinguished is a cause of confusion; sometimes, indeed, it is
+possible to get confused between the two levels while developing PyPy.
+However, the existence of the two levels for the same language also
+offers a powerful advantage, fully offsetting the possibility of
+confusion (and then some): PyPy lets you use application-level code for
+the purpose of implementing interpreter-level operations.
+
+Application-level code is much higher-level, and therefore easier to
+write and debug.  Instead of implementing a dict object's update method
+by simple, application-level code that goes something like::
+
+    def app_dict_update__ANY_ANY(d, o):
+        for k in o.keys():
+            d[k] = o[k]