[pypy-svn] r38907 - pypy/dist/pypy/doc

mwh at codespeak.net mwh at codespeak.net
Thu Feb 15 16:39:08 CET 2007


Author: mwh
Date: Thu Feb 15 16:39:05 2007
New Revision: 38907

Modified:
   pypy/dist/pypy/doc/faq.txt
Log:
review the faq


Modified: pypy/dist/pypy/doc/faq.txt
==============================================================================
--- pypy/dist/pypy/doc/faq.txt	(original)
+++ pypy/dist/pypy/doc/faq.txt	Thu Feb 15 16:39:05 2007
@@ -12,7 +12,7 @@
 What is PyPy?
 -------------
 
-PyPy is both a Python reimplemenation and a framework to implement
+PyPy is both a Python reimplementation and a framework to implement
 interpreters and virtual machines for programming languages,
 especially dynamic ones. PyPy tries to find new answers about ease of
 creation, flexibility, maintainability and speed trade-offs for
@@ -24,40 +24,40 @@
 
 .. _`drop in replacement`:
 
------------------------------------------
-Is PyPy a drop in replacement of CPython?
------------------------------------------
-
-Not completely yet. There are various areas where PyPy is lacking, such as
-threading_ and `extension modules`_. The language features (including built in
-types and functions) are very complete and well tested, though. That means that
-projects not using many extension modules can probably directly use PyPy. A
+------------------------------------------
+Is PyPy a drop in replacement for CPython?
+------------------------------------------
+
+Not completely, at least not yet. There are various areas where PyPy is lacking, such as
+threading_ and `extension modules`_. The language features (including builtin
+types and functions) are very complete and well tested, though. This means that
+a project not using many extension modules can probably directly use PyPy. A
 project using extension modules might get some problems, though.
 
-------------------------------
-On what platforms does it run?
-------------------------------
+--------------------------------
+On what platforms does PyPy run?
+--------------------------------
 
 PyPy is regularly and extensively tested on Linux machines and on Mac
 OS X and mostly works under Windows too (but is tested there less
 extensively). PyPy needs a CPython running on the target platform to
-bootstrap, cross compilation is not really meant to work,
-currently. At the moment you need CPython 2.4 for the translation
-process, 2.5 is not fully supported.
-
-Currently (due to time restrictions) we are not trying hard to make PyPy support
-64 bit platforms. While this seems to still mostly work out, a few modules won't
-work on 64 bit machines, such as ``bz2``.
-
-----------------------------------------------
-Which Python version (2.x?) does PyPy support?
-----------------------------------------------
-
-PyPy currently targets to be fully compatible with Python 2.4. That means that
-it contains the stdandard library of Python 2.4 and that it supports 2.4
-features (such as decorators) but not the 2.5 features (with statement, ternary
-operators).  The 2.5 features will probably be eventually suported, the most
-important reasons why nobody is working on them is that we did not promise this
+bootstrap, as cross compilation is not really meant to work yet.
+At the moment you need CPython 2.4 for the translation process, 2.5 is
+not fully supported.
+
+Currently (due to time restrictions) we are not trying hard to support
+PyPy in a 64 bit environment.  While things seem to mostly work, a few
+modules won't work on 64 bit machines, such as ``bz2``.
+
+------------------------------------------------
+Which Python version (2.x?) does PyPy implement?
+------------------------------------------------
+
+PyPy currently aims to be fully compatible with Python 2.4. That means that
+it contains the standard library of Python 2.4 and that it supports 2.4
+features (such as decorators) but not the 2.5 features (with statement, the ternary
+operator).  The 2.5 features will probably be eventually supported, the most
+important reason why nobody is working on them is that we did not promise this
 to the EU and have currently enough other tasks.
 
 .. _threading:
@@ -66,7 +66,7 @@
 Do threads work?  What are the modules that work?
 -------------------------------------------------
 
-Operating-System threads work in a limited way. If you enable the ``thread``
+Operating system-level threads work in a limited way. If you enable the ``thread``
 module then PyPy will get support for GIL based threading. One limitation is
 that not that many IO operations actually release the GIL, which reduces the
 usefulness of threads. On the other hand, PyPy fully supports `stackless-like
@@ -84,7 +84,7 @@
 
  * mixed module implementations: exceptions, sys, __builtin__, posix
    _codecs, gc, _weakref, array, marshal, errno, math, _sre,  parser, symbol,
-   _random, socket, unicodedata, mmap, fcntl, time, select, bz2, crypt, 
+   _random, socket, unicodedata, mmap, fcntl, time, select, bz2, crypt,
    signal
 
 
@@ -99,22 +99,23 @@
 
 No and there are no current plans to support this. CPython extension modules
 rely heavily on CPython's C API which contains a lot of implementation details
-like reference counting, exact C-level objects implementations etc.
+like reference counting, exact C-level object implementation etc.
 
-Although if your module uses ctypes rather than C-level code, there is a hope.
-You can try to write a mixed module (see next question).
+Although if your module uses ctypes rather than C-level code, there is
+a hope -- you can try to write a mixed module (see next question).
 
 ------------------------------------------
 How do I write extension modules for PyPy?
 ------------------------------------------
 
-PyPy extension modules are in the form of so called `mixed modules`_,
-at the moment they all need to be translated together with the rest of PyPy.
+PyPy extension modules are written in the form of `mixed modules`_, so
+called because they can contain a mixture of compiled and interpreted
+Python code.  At the moment they all need to be translated together with the rest of PyPy.
 
-We have a proof concept in what we call the `extension compiler`_ and
+We have a proof concept of what we call the `extension compiler`_ and
 our support for a static variant of ctypes interface (`rctypes`_) to
 help with their development. At the moment both have quite some rough
-edges, also cross compilation to CPython extensions which is possible
+edges, also cross compilation to CPython extensions, while possible,
 doesn't deliver completely satisfying results.  This area is going to
 improve over time.
 
@@ -135,7 +136,7 @@
 a factor of 2000. The first translated version was roughly 300 times slower
 than CPython. In later versions, we increased the speed. CPython was about
 10-20 times as fast as version 0.8.0, 4-7 times as fast as version 0.9 and
-2.4 - 5 times as fast as the current version (0.99).
+2 - 5 times as fast as the current version (0.99).
 Note that the speed heavily depends on the enabled options at compile time.
 
 
@@ -145,11 +146,11 @@
 What is this talk about a JavaScript and a Prolog interpreter in PyPy?
 -----------------------------------------------------------------------
 
-Since a Python interpreter is a rather large and intricate thing, our toolsuite
-became quite advanced to support it. Therefore people had the idea of using it
+Since a Python interpreter is a rather large and intricate thing, our tool suite
+has become quite advanced to support it. This resulted in people having the idea of using it
 to implement interpreters for other dynamic languages than Python and get a lot
 of things for free (translation to various languages, stackless features,
-garbage collection, implementation of various things like arbitraryly long
+garbage collection, implementation of various things like arbitrarily long
 integers). Therefore people started to implement a `JavaScript interpreter`_
 (Leonardo Santagada as his Summer of PyPy project) and a `Prolog interpreter`_
 (Carl Friedrich Bolz as his Masters thesis). Both projects are undocumented and
@@ -175,7 +176,7 @@
 Coming to a sprint is usually also the best way to get into PyPy development.
 If you want to start on your own, take a look at the list of `project
 suggestions`_. If you get stuck or need advice, `contact us`_. Usually IRC is
-the most immediate mean to get feedback (at least during some parts of the day,
+the most immediate way to get feedback (at least during some parts of the day;
 many PyPy developers are in Europe) and the mailing list is better for long
 discussions.
 
@@ -204,9 +205,9 @@
 ------------------------------
 
 RPython is a restricted subset of the Python language. The restrictions are to
-ensure that type inference (and eventually translation to other languages) of
+ensure that type inference (and so, ultimately, translation to other languages) of
 the program is possible. These restrictions only apply after the full import
-happened, so at import time arbitrary Python code can be executed. Another
+happens, so at import time arbitrary Python code can be executed. Another
 important point is that the property of "being RPython" always applies to a full
 program, not to single functions or modules (the translation tool chain does a
 full program analysis).
@@ -272,8 +273,8 @@
 No.  PyPy always runs your code in its own interpreter, which is a
 full and compliant Python 2.4 interpreter.  RPython_ is only the
 language in which parts of PyPy itself are written and extension
-modules for it.  The answer whether something needs to be written as
-an extension module, apart from glueing external libraries, will
+modules for it.  The answer to whether something needs to be written as
+an extension module, apart from the "gluing to external libraries" reason, will
 change over time as speed for normal Python code improves.
 
 -------------------------
@@ -289,7 +290,7 @@
 * Low level backends: C_, LLVM_
 * High level backends: CLI_, JVM_, JavaScript_
 
-Partially implemented backends:
+Partially implemented backends (both high-level):
 
 * Squeak_, `Common Lisp`_
 
@@ -323,7 +324,7 @@
 
 You can have a look at intermediate C source code, which is (at the
 moment) put in ``/tmp/usession-*/testing_1/testing_1.c``.  Of course,
-all the function and stuff indirectly used by your ``entry_point()``
+all the functions and stuff used directly and indirectly by your ``entry_point()``
 function has to be RPython_.
 
 



More information about the Pypy-commit mailing list