[pypy-svn] r55620 - pypy/dist/pypy/doc
arigo at codespeak.net
arigo at codespeak.net
Fri Jun 6 09:38:16 CEST 2008
Date: Fri Jun 6 09:38:14 2008
New Revision: 55620
Update some entries of the FAQ.
--- pypy/dist/pypy/doc/_ref.txt (original)
+++ pypy/dist/pypy/doc/_ref.txt Fri Jun 6 09:38:14 2008
@@ -10,6 +10,7 @@
.. _`pypy/annotation/model.py`: ../../pypy/annotation/model.py
.. _`bin/`: ../../pypy/bin
.. _`config/`: ../../pypy/config
+.. _`pypy/config/pypyoption.py`: ../../pypy/config/pypyoption.py
.. _`doc/`: ../../pypy/doc
.. _`doc/config/`: ../../pypy/doc/config
.. _`doc/discussion/`: ../../pypy/doc/discussion
--- pypy/dist/pypy/doc/faq.txt (original)
+++ pypy/dist/pypy/doc/faq.txt Fri Jun 6 09:38:14 2008
@@ -54,9 +54,7 @@
At the moment you need CPython 2.4 (with ctypes 0.9.9.6 or newer) or
CPython 2.5 for the translation process.
-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``.
+PyPy also basically works in a 64-bit Linux environment.
Which Python version (2.x?) does PyPy implement?
@@ -64,10 +62,8 @@
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.
+features (such as decorators). The 2.5 features (e.g. the ``with`` statement,
+the ternary operator) are in progress.
@@ -75,26 +71,24 @@
Do threads work? What are the modules that work?
-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
+Operating system-level threads basically work. If you enable the ``thread``
+module then PyPy will get support for GIL based threading.
+Note that PyPy also fully supports `stackless-like
microthreads`_ (although both cannot be mixed yet).
As for other modules: The general rule of thumb is that pure-Python modules
-work, C extension modules don't. Some of the C extension modules of the standard
+work, C extension modules don't. However, many of the C extension modules
+of the standard
library have been re-implemented in pure Python or as a mixed module (for some
-there were also older pure-Python versions available). A (probably incomplete)
+there were also older pure-Python versions available). The list of supported
+modules can be found as follows:
- * pure Python implementations: binascii, cmath, collections, cPickle,
- cStringIO, datetime, functional, imp, itertools, md5, operator,
- sha, struct
- * 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,
- signal, readline (incomplete)
+ * pure Python implementations: all the modules found in the `pypy/lib/`_
+ * mixed module implementations: all the modules listed in
+ ``essential_modules``, ``default_modules`` and ``working_modules``
+ in `pypy/config/pypyoption.py`_.
.. _`stackless-like microthreads`: stackless.html
@@ -110,8 +104,7 @@
rely heavily on CPython's C API which contains a lot of implementation details
like reference counting, exact C-level object implementation and layout 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).
+A module based on ctypes is a different matter -- we support these nowadays.
The long-term answer might be different. In principle, it should be possible
for PyPy to support the CPython C API (or at least a large subset of its
@@ -122,11 +115,10 @@
How do I write extension modules for 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.
+See `Writing extension modules for PyPy`__.
+.. __: extending.html
-.. _`mixed modules`: coding-guide.html#mixed-module-mechanism
.. _`slower than CPython`:
.. _`how fast is pypy`:
@@ -141,17 +133,16 @@
CPython, the version of PyPy that still runs on top of CPython is slower
by a factor of 2000. The first translated version was roughly 300 times
slower than CPython, a number which we decreased release after release
-to the current point, where PyPy is only between 1.7 and 4 times slower
-than CPython. Note that the speed heavily depends on the options
-enabled at compile time.
+to the current point, where PyPy is somewhere between 1 and 2, i.e. it
+is as fast as CPython in some cases, and up to twice as slow in other
+cases. Note that the speed heavily depends on the options enabled at
The integration of the work on the Just-In-Time compiler has just
-started; it can be `manually enabled`_ and gives good results on
-functions doing integer arithmetic (60 times faster than CPython,
-i.e. within 20% of recoding the function in C and compiling with ``gcc``
+started; it is not yet ready enough to give useful speed-ups. See
-.. _`manually enabled`: jit/status.html
+.. __: jit/status.html
More information about the Pypy-commit