Philip Jenvey  committed c2a09b9 Merge

merge default

  • Participants
  • Parent commits 08881cb, d343da0
  • Branches py3k

Comments (0)

Files changed (6)

File pypy/doc/architecture.rst

  * a compliant, flexible and fast implementation of the Python_ Language 
    which uses the above toolchain to enable new advanced high-level features 
-   without having to encode the low-level details.
+   without having to encode the low-level details.  We call this PyPy.
 By separating concerns in this way, our implementation
 of Python - and other dynamic languages - is able to automatically
 High Level Goals
-PyPy - the Translation Framework 
+RPython - the Translation Toolchain
 Traditionally, language interpreters are written in a target platform language
 very challenging because of the involved complexity.
-PyPy - the Python Interpreter 
+PyPy - the Python Interpreter
 Our main motivation for developing the translation framework is to
 of `Extreme Programming`_, the architecture of PyPy has evolved over time
 and continues to evolve.  Nevertheless, the high level architecture is 
 stable. As described above, there are two rather independent basic
-subsystems: the `Python Interpreter`_ and the `Translation Framework`_.
+subsystems: the `PyPy Python Interpreter`_ and the `RPython Translation Toolchain`_.
 .. _`translation framework`:
-The Translation Framework
+RPython Translation Toolchain
 The job of the RPython toolchain is to translate RPython_ programs
 * Optionally, `various transformations`_ can then be applied which, for
   example, perform optimizations such as inlining, add capabilities
-  such as stackless-style concurrency (deprecated), or insert code for the
+  such as stackless-style concurrency, or insert code for the
   `garbage collector`_.
 * Then, the graphs are converted to source code for the target platform
 .. _`standard interpreter`: 
 .. _`python interpreter`: 
-The Python Interpreter
+PyPy Python Interpreter
 PyPy's *Python Interpreter* is written in RPython and implements the

File pypy/doc/faq.rst

 CPython extension and replace it with a pure python version that the
 JIT can see.
-We fully support ctypes-based extensions.
+We fully support ctypes-based extensions. But for best performance, we
+recommend that you use the cffi_ module to interface with C code.
 For information on which third party extensions work (or do not work) 
 with PyPy see the `compatibility wiki`_.
 .. _`extension modules`: cpython_differences.html#extension-modules
 .. _`cpython differences`: cpython_differences.html
-.. _`compatibility wiki`:
+.. _`compatibility wiki`:
+.. _cffi:
 On which platforms does PyPy run?
 bootstrap, as cross compilation is not really meant to work yet.
 At the moment you need CPython 2.5 - 2.7
 for the translation process. PyPy's JIT requires an x86 or x86_64 CPU.
+(There has also been good progress on getting the JIT working for ARMv7.)
 Which Python version (2.x?) does PyPy implement?
 * Second, and perhaps most important: do you have a really good reason
   for writing the module in RPython in the first place?  Nowadays you
   should really look at alternatives, like writing it in pure Python,
-  using ctypes if it needs to call C code.  Other alternatives are being
-  developed too (as of summer 2011), like a Cython binding.
+  using cffi_ if it needs to call C code.
 In this context it is not that important to be able to translate
 RPython modules independently of translating the complete interpreter.

File pypy/doc/getting-started-dev.rst

 The translator is a tool based on the PyPy interpreter which can translate
 sufficiently static RPython programs into low-level code (in particular it can
 be used to translate the `full Python interpreter`_). To be able to experiment with it
-you need to:
+you need to download and install the usual (CPython) version of:
-  * Download and install Pygame_.
-  * Download and install `Dot Graphviz`_ 
+  * Pygame_
+  * `Dot Graphviz`_
 To start the interactive translator shell do::

File pypy/doc/whatsnew-head.rst

 Moves optimized JIT frames from stack to heap. As a side effect it enables
 stackless to work well with the JIT on PyPy. Also removes a bunch of code from
 the GC which fixes cannot find gc roots.
+.. branch: pycon2013-doc-fixes
+Documentation fixes after going through the docs at PyCon 2013 sprint.

File pypy/objspace/std/

         for w_k, w_v in list_pairs_w:
             w_self.setitem(w_k, w_v)
+    def setitem(self, w_key, w_value):
+        self.strategy.setitem(self, w_key, w_value)
+    def setitem_str(self, key, w_value):
+        self.strategy.setitem_str(self, key, w_value)
 def _add_indirections():
-    dict_methods = "setitem setitem_str getitem \
+    dict_methods = "getitem \
                     getitem_str delitem length \
                     clear w_keys values \
                     items iterkeys itervalues iteritems setdefault \

File pypy/objspace/std/

         return[ for key in self.unerase(w_dict.dstorage)[0]])
     def setitem(self, w_dict, w_key, w_value):
-        space =
         if self.is_correct_type(w_key):
             self.setitem_str(w_dict, self.unwrap(w_key), w_value)