[Python-Dev] Return type of round, floor, and ceil in 2.6

Jeffrey Yasskin jyasskin at gmail.com
Sun Jan 6 10:50:42 CET 2008


On Jan 5, 2008 4:20 PM, Tim Peters <tim.peters at gmail.com> wrote:
> [Guido]
> > Wow. Do you have an opinion as to whether we should adopt
> > round-to-even at all (as a default)?
>
> Yes:  yes :-)

Thanks for the suggestion, Tim. Here's a new proposed patch to the
pep. It still allows type-defined half-rounding behavior so that
Decimal can follow the current context. I'll submit it tomorrow unless
there are significant objections.

Index: pep-3141.txt
===================================================================
--- pep-3141.txt        (revision 59739)
+++ pep-3141.txt        (working copy)
@@ -205,8 +205,12 @@
         def __round__(self, ndigits:Integral=None):
             """Rounds self to ndigits decimal places, defaulting to 0.

-            If ndigits is omitted or None, returns an Integral, otherwise
-            returns a Real. Rounds half toward even.
+            If ndigits is omitted or None, returns an Integral,
+            otherwise returns a Real, preferably of the same type as
+            self. Types may choose which direction to round half. For
+            example, float rounds half toward even, and Decimal rounds
+            it according to the current context.
+
             """
             raise NotImplementedError

@@ -428,10 +432,14 @@
    least Integral ``>= x``.

 4. ``__round__(self)``, called from ``round(x)``, which returns the
-   Integral closest to ``x``, rounding half toward even. There is also
-   a 2-argument version, ``__round__(self, other)``, called from
-   ``round(x, y)``, which should return a Real.
+   Integral closest to ``x``, rounding half as the type chooses.
+   ``float`` will change in 3.0 to round half toward even. There is
+   also a 2-argument version, ``__round__(self, ndigits)``, called
+   from ``round(x, ndigits)``, which should return a Real.

+In 2.6, ``math.floor``, ``math.ceil``, and ``round`` will continue to
+return floats.
+
 Because the ``int()`` conversion implemented by ``float`` (and by
 ``decimal.Decimal``) is equivalent to but less explicit than
 ``trunc()``, let's remove it. (Or, if that breaks too much, just add a

-- 
Namasté,
Jeffrey Yasskin


More information about the Python-Dev mailing list