[pypy-svn] r68995 - pypy/trunk/pypy/doc

[arigo at codespeak.net]

Author: arigo
Date: Thu Nov  5 18:29:12 2009
New Revision: 68995

Modified:
   pypy/trunk/pypy/doc/cpython_differences.txt
Log:
Kill the new paragraph; rephrase and move its content closer to
the start, which was already explaining part of it.


Modified: pypy/trunk/pypy/doc/cpython_differences.txt
==============================================================================
--- pypy/trunk/pypy/doc/cpython_differences.txt	(original)
+++ pypy/trunk/pypy/doc/cpython_differences.txt	Thu Nov  5 18:29:12 2009
@@ -107,6 +107,15 @@
 adopted by Jython or IronPython (or any other port of Python to Java or
 .NET, like PyPy itself).
 
+This affects the precise time at which __del__ methods are called, which
+is not reliable in PyPy (nor Jython nor IronPython).  It also means that
+weak references may stay alive for a bit longer than expected.  This
+makes "weak proxies" (as returned by ``weakref.proxy()``) somewhat less
+useful: they will appear to stay alive for a bit longer in PyPy, and
+suddenly they will really be dead, raising a ``ReferenceError`` on the
+next access.  Any code that uses weak proxies must carefully catch such
+``ReferenceError`` at any place that uses them.
+
 There are a few extra implications for the difference in the GC.  Most
 notably, if an object has a __del__, the __del__ is never called more
 than once in PyPy; but CPython will call the same __del__ several times
@@ -120,17 +129,6 @@
 .. __: http://morepypy.blogspot.com/2008/02/python-finalizers-semantics-part-1.html
 .. __: http://morepypy.blogspot.com/2008/02/python-finalizers-semantics-part-2.html
 
-Note that the time at which __del__ is called is not well-defined in any
-implementation apart from CPython.  A __del__ method may appear to be
-called sometimes later in PyPy; for example, a file may stay open for a
-bit longer, which can have visible effects (e.g. a file opened for
-writing might still contain data not flushed yet).  This also makes
-"weak proxies" less useful (see ``weakref.proxy()``).  They will appear
-to stay alive a bit longer in PyPy, and suddenly they will really be
-dead, raising a ``ReferenceError`` on the next access.  Any code that
-uses weak proxies must carefully catch such ``ReferenceError`` at any
-place that uses them.
-
 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