[Python-checkins] r56675 - peps/trunk/pep-3141.txt

[guido.van.rossum]

Author: guido.van.rossum
Date: Thu Aug  2 21:43:38 2007
New Revision: 56675

Modified:
   peps/trunk/pep-3141.txt
Log:
New ersion by Jeffrey, nearing perfection. :-)


Modified: peps/trunk/pep-3141.txt
==============================================================================
--- peps/trunk/pep-3141.txt	(original)
+++ peps/trunk/pep-3141.txt	Thu Aug  2 21:43:38 2007
@@ -7,7 +7,7 @@
 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 @@
 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 @@
 
 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 @@
 
         @abstractmethod
         def __floordiv__(self, other):
-            """The floor() of self/other."""
+            """The floor() of self/other. Integral."""
             raise NotImplementedError
 
         @abstractmethod
@@ -220,6 +225,7 @@
             """< on Reals defines a total ordering, except perhaps for NaN."""
             raise NotImplementedError
 
+        @abstractmethod
         def __le__(self, other): 
             raise NotImplementedError
 
@@ -380,19 +386,20 @@
    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