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

[xoraxax at codespeak.net]

Author: xoraxax
Date: Wed May 28 18:16:44 2008
New Revision: 55360

Modified:
   pypy/dist/pypy/doc/cpython_differences.txt
Log:
Make it a bit more obvious that pypy is full of garbage collectors.

Modified: pypy/dist/pypy/doc/cpython_differences.txt
==============================================================================
--- pypy/dist/pypy/doc/cpython_differences.txt	(original)
+++ pypy/dist/pypy/doc/cpython_differences.txt	Wed May 28 18:16:44 2008
@@ -13,12 +13,12 @@
 Differences related to garbage collection strategies
 ----------------------------------------------------
 
-PyPy's garbage collector is not based on reference counting, so the
-objects are not freed instantly when they are no longer reachable.  The
-most obvious effect of this is that files are not promptly closed when
-they go out of scope.  For files that are opened for writing, data can
-be left sitting in their output buffers for a while, making the on-disk
-file appear empty or truncated.
+Most of the garbage collectors used or implemented by PyPy are not based on
+reference counting, so the objects are not freed instantly when they are no
+longer reachable.  The most obvious effect of this is that files are not
+promptly closed when they go out of scope.  For files that are opened for
+writing, data can be left sitting in their output buffers for a while, making
+the on-disk file appear empty or truncated.
 
 Fixing this is essentially not possible without forcing a
 reference-counting approach to garbage collection.  The effect that you
@@ -34,7 +34,8 @@
 than once in PyPy; but CPython will call the same __del__ several times
 if the object is resurrected and dies again.
 
-The built-in function ``id()`` returns numbers that are not addresses.
+The built-in function ``id()`` returns numbers that are not addresses
+for most of PyPy's garbage collectors.
 This is most visible in the default repr: a typical PyPy object can
 pretend to be located ``at 0x00000009``.  This is just its ``id()``, not
 its real address (because the physical address can change).