Documented 2.2's approach to long true division (this was implemented

a long time ago).
Spelled out that true division can lose information for ints as well as
longs.
Added a "Resolved Issues" section, and split one of the Open Issues
into three Resolved issues.

pep-0238.txt

@@ -318,16 +318,25 @@ Semantics of True Division
     return a float (2.0), not an int.  For floats and complex, it will
     be the same as classic division.
 
-    Note that for long arguments, true division may lose information;
+    The 2.2 implementation of true division acts as if the float type
-    this is in the nature of true division (as long as rationals are
+    had unbounded range, so that overflow doesn't occur unless the
-    not in the language).  Algorithms that consciously use longs
+    magnitude of the mathematical *result* is too large to represent
-    should consider using //.
+    as a float.  For example, after "x = 1L << 40000", float(x) raises
+    OverflowError (note that this is also new in 2.2:  previously the
+    outcome was platform-dependent, most commonly a float infinity).  But
+    x/x returns 1.0 without exception, while x/1 raises OverflowError.
+
+    Note that for int and long arguments, true division may lose
+    information; this is in the nature of true division (as long as
+    rationals are not in the language).  Algorithms that consciously
+    use longs should consider using //, as true division of longs
+    retains no more than 53 bits of precision (on most platforms).
 
     If and when a rational type is added to Python (see PEP 239[2]),
     true division for ints and longs should probably return a
-    rational.  This avoids the problem with true division of longs
+    rational.  This avoids the problem with true division of ints and
-    losing information.  But until then, for consistency, float is the
+    longs losing information.  But until then, for consistency, float is
-    only choice for true division.
+    the only choice for true division.
 
 
 The Future Division Statement
@@ -370,15 +379,6 @@ Open Issues
       need the same.  These usually have enough control over the
       library packages available in their environment.
 
-    - For very large long integers, the definition of true division as
-      returning a float causes problems, since the range of Python
-      longs is much larger than that of Python floats.  This problem
-      will disappear if and when rational numbers are supported.  In
-      the interim, maybe the long-to-float conversion could be made to
-      raise OverflowError if the long is out of range.  Tim Peters
-      will make sure that whenever an in-range float is returned,
-      decent precision is guaranteed.
-
     - For classes to have to support all three of __div__(),
       __floordiv__() and __truediv__() seems painful; and what to do
       in 3.0?  Maybe we only need __div__() and __floordiv__(), or
@@ -386,6 +386,37 @@ Open Issues
       __div__() second.
 
 
+Resolved Issues
+
+    - Issue:  For very large long integers, the definition of true
+      division as returning a float causes problems, since the range of
+      Python longs is much larger than that of Python floats.  This
+      problem will disappear if and when rational numbers are supported.
+
+      Resolution:  For long true division, Python uses an internal
+      float type with native double precision but unbounded range, so
+      that OverflowError doesn't occur unless the quotient is too large
+      to represent as a native double.
+
+    - Issue:  In the interim, maybe the long-to-float conversion could be
+      made to raise OverflowError if the long is out of range.
+
+      Resolution:  This has been implemented, but, as above, the
+      magnitude of the inputs to long true division doesn't matter; only
+      the magnitude of the quotient matters.
+
+    - Issue:  Tim Peters will make sure that whenever an in-range float
+      is returned, decent precision is guaranteed.
+
+      Resolution:  Provided the quotient of long true division is
+      representable as a float, it suffers no more than 3 rounding
+      errors:  one each for converting the inputs to an internal float
+      type with native double precision but unbounded range, and
+      one more for the division.  However, note that if the magnitude
+      of the quotient is too *small* to represent as a native double,
+      0.0 is returned without exception ("silent underflow").
+
+
 FAQ
 
     Q. When will Python 3.0 be released?