New ersion by Jeffrey, nearing perfection. :-)

pep-3141.txt

@@ -7,7 +7,7 @@ Status: Draft
 Type: Standards Track
 Content-Type: text/x-rst
 Created: 23-Apr-2007
-Post-History: 25-Apr-2007, 16-May-2007, xx-Aug-2007
+Post-History: 25-Apr-2007, 16-May-2007, 02-Aug-2007
 
 
 Abstract
@@ -39,6 +39,9 @@ general strategy for implementing some of the methods. It uses
 terminology from PEP 3119, but the hierarchy is intended to be
 meaningful for any systematic method of defining sets of classes.
 
+The type checks in the standard library should use these classes
+instead of the concrete built-ins.
+
 
 Numeric Classes
 ---------------
@@ -52,7 +55,9 @@ overloading; it doesn't provide any operations. ::
 
 Most implementations of complex numbers will be hashable, but if you
 need to rely on that, you'll have to check it explicitly: mutable
-numbers are supported by this hierarchy. ::
+numbers are supported by this hierarchy. **Open issue:** Should
+__pos__ coerce the argument to be an instance of the type it's defined
+on? Why do the builtins do this? ::
 
     class Complex(Number):
         """Complex defines the operations that work on the builtin complex type.
@@ -199,7 +204,7 @@ totally ordered except for NaNs (which this PEP basically ignores). ::
 
         @abstractmethod
         def __floordiv__(self, other):
-            """The floor() of self/other."""
+            """The floor() of self/other. Integral."""
             raise NotImplementedError
 
         @abstractmethod
@@ -220,6 +225,7 @@ totally ordered except for NaNs (which this PEP basically ignores). ::
             """< on Reals defines a total ordering, except perhaps for NaN."""
             raise NotImplementedError
 
+        @abstractmethod
         def __le__(self, other): 
             raise NotImplementedError
 
@@ -380,19 +386,20 @@ functions. All of these return Integrals rather than Reals.
    least Integral ``>= x``.
 
 4. ``__round__(self)``, called from ``round(x)``, with returns the
-   Integral closest to ``x``, rounding half toward even. We could
-   support the 2-argument version, but then we'd only return an
-   Integral if the second argument were ``<= 0``.
+   Integral closest to ``x``, rounding half toward even. **Open
+   issue:** We could support the 2-argument version, but then we'd
+   only return an Integral if the second argument were ``<= 0``.
 
 5. ``__properfraction__(self)``, called from a new function,
    ``math.properfraction(x)``, which resembles C's ``modf()``: returns
    a pair ``(n:Integral, r:Real)`` where ``x == n + r``, both ``n``
    and ``r`` have the same sign as ``x``, and ``abs(r) < 1``. **Open
-   issue:** Oh, we already have ``math.modf``. Do we want to keep the
-   bad name?
+   issue:** Oh, we already have ``math.modf``. What name do we want
+   for this? Should we use divmod(x, 1) instead?
 
 Because the ``int()`` conversion from ``float`` is equivalent to but
-less explicit than ``trunc()``, let's remove it.
+less explicit than ``trunc()``, let's remove it. (Or, if that breaks
+too much, just add a deprecation warning.)
 
 ``complex.__{divmod,mod,floordiv,int,float}__`` should also go
 away. These should continue to raise ``TypeError`` to help confused