New ersion by Jeffrey, nearing perfection. :-)
This commit is contained in:
parent
2ca9a1402a
commit
1e3f4e7c1c
25
pep-3141.txt
25
pep-3141.txt
|
@ -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
|
||||||
|
|
Loading…
Reference in New Issue