Some small clarifications based on c.l.py feedback. Added open issue

about __truediv__ vs. __div__ in Python 3.0.

pep-0238.txt

@@ -171,7 +171,7 @@ Alternatives
       operations, the int and the float value could be miles apart,
       it's unclear which value should be used in comparisons, and of
       course many contexts (like conversion to string) don't have a
-      clear integer or float context.
+      clear integer or float preference.
 
     - Use a directive to use specific division semantics in a module,
       rather than a future statement.  This retains classic division
@@ -293,7 +293,7 @@ Semantics of Floor Division
 
       3.5//2.0 == 1.0
 
-    For complex numbers, // raises an exception, since float() of a
+    For complex numbers, // raises an exception, since floor() of a
     complex number is not allowed.
 
     For user-defined classes and extension types, all semantics are up
@@ -338,6 +338,10 @@ The Future Division Statement
 
 Open Issues
 
+    We expect that these issues will be resolved over time, as more
+    feedback is received or we gather more experience with the initial
+    implementation.
+
     - It has been proposed to call // the quotient operator, and the /
       operator the ratio operator.  I'm not sure about this -- for
       some people quotient is just a synonym for division, and ratio
@@ -362,6 +366,12 @@ Open Issues
       the interim, maybe the long-to-float conversion could be made to
       raise OverflowError if the long is out of range.
 
+    - 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
+      maybe at least true division should try __truediv__() first and
+      __div__() second.
+
 
 FAQ
 
@@ -389,9 +399,10 @@ FAQ
        while the documentation of int() says that int() can round or
        truncate depending on the C implementation, we know of no C
        implementation that doesn't truncate, and we're going to change
-       the spec for int() to promise truncation.  Note that for
-       negative ints, classic division (and floor division) round
-       towards negative infinity, while int() rounds towards zero.
+       the spec for int() to promise truncation.  Note that classic
+       division (and floor division) round towards negative infinity,
+       while int() rounds towards zero, giving different answers for
+       negative numbers.
 
     Q. How do I specify the division semantics for input(), compile(),
        execfile(), eval() and exec?