Alex Gaynor committed d343da0 Merge

merged upstream

Comments (0)

Files changed (5)


  * 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
 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.


 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::


 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.


 ssl_external('SSLv23_method', [], SSL_METHOD)
 ssl_external('SSL_CTX_use_PrivateKey_file', [SSL_CTX, rffi.CCHARP, rffi.INT], rffi.INT)
 ssl_external('SSL_CTX_use_certificate_chain_file', [SSL_CTX, rffi.CCHARP], rffi.INT)
-ssl_external('SSL_CTX_get_options', [SSL_CTX], rffi.INT, macro=True)
-ssl_external('SSL_CTX_set_options', [SSL_CTX, rffi.INT], rffi.INT, macro=True)
+ssl_external('SSL_CTX_get_options', [SSL_CTX], rffi.LONG, macro=True)
+ssl_external('SSL_CTX_set_options', [SSL_CTX, rffi.LONG], rffi.LONG, macro=True)
-    ssl_external('SSL_CTX_clear_options', [SSL_CTX, rffi.INT], rffi.INT,
+    ssl_external('SSL_CTX_clear_options', [SSL_CTX, rffi.LONG], rffi.LONG,
 ssl_external('SSL_CTX_ctrl', [SSL_CTX, rffi.INT, rffi.INT, rffi.VOIDP], rffi.INT)
 ssl_external('SSL_CTX_set_verify', [SSL_CTX, rffi.INT, rffi.VOIDP], lltype.Void)