New ersion by Jeffrey, nearing perfection. :-)

This commit is contained in:
Guido van Rossum 2007-08-02 19:43:38 +00:00
parent 2ca9a1402a
commit 1e3f4e7c1c
1 changed files with 16 additions and 9 deletions

View File

@ -7,7 +7,7 @@ Status: Draft
Type: Standards Track Type: Standards Track
Content-Type: text/x-rst Content-Type: text/x-rst
Created: 23-Apr-2007 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 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 terminology from PEP 3119, but the hierarchy is intended to be
meaningful for any systematic method of defining sets of classes. 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 Numeric Classes
--------------- ---------------
@ -52,7 +55,9 @@ overloading; it doesn't provide any operations. ::
Most implementations of complex numbers will be hashable, but if you Most implementations of complex numbers will be hashable, but if you
need to rely on that, you'll have to check it explicitly: mutable 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): class Complex(Number):
"""Complex defines the operations that work on the builtin complex type. """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 @abstractmethod
def __floordiv__(self, other): def __floordiv__(self, other):
"""The floor() of self/other.""" """The floor() of self/other. Integral."""
raise NotImplementedError raise NotImplementedError
@abstractmethod @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.""" """< on Reals defines a total ordering, except perhaps for NaN."""
raise NotImplementedError raise NotImplementedError
@abstractmethod
def __le__(self, other): def __le__(self, other):
raise NotImplementedError raise NotImplementedError
@ -380,19 +386,20 @@ functions. All of these return Integrals rather than Reals.
least Integral ``>= x``. least Integral ``>= x``.
4. ``__round__(self)``, called from ``round(x)``, with returns the 4. ``__round__(self)``, called from ``round(x)``, with returns the
Integral closest to ``x``, rounding half toward even. We could Integral closest to ``x``, rounding half toward even. **Open
support the 2-argument version, but then we'd only return an issue:** We could support the 2-argument version, but then we'd
Integral if the second argument were ``<= 0``. only return an Integral if the second argument were ``<= 0``.
5. ``__properfraction__(self)``, called from a new function, 5. ``__properfraction__(self)``, called from a new function,
``math.properfraction(x)``, which resembles C's ``modf()``: returns ``math.properfraction(x)``, which resembles C's ``modf()``: returns
a pair ``(n:Integral, r:Real)`` where ``x == n + r``, both ``n`` 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 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 issue:** Oh, we already have ``math.modf``. What name do we want
bad name? for this? Should we use divmod(x, 1) instead?
Because the ``int()`` conversion from ``float`` is equivalent to but 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 ``complex.__{divmod,mod,floordiv,int,float}__`` should also go
away. These should continue to raise ``TypeError`` to help confused away. These should continue to raise ``TypeError`` to help confused