Armin Rigo committed 054d40e

Kill the new paragraph; rephrase and move its content closer to
the start, which was already explaining part of it.

  • Participants
  • Parent commits 0246d9c

Comments (0)

Files changed (1)

File pypy/doc/cpython_differences.txt

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