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

[Jeffrey Yasskin]

On Jan 5, 2008 8:56 AM, Guido van Rossum <guido at python.org> wrote:
> I think the consensus is against round-to-even in 3.0 -- this requires
> a PEP update as well as code changes. (Sorry for having caused so much
> extra work, I should have flagged this earlier.)

I'm not convinced that speed is a real issue in this case, since this
is only the explicit round() operation and not rounding for arithmetic
operations. But consistency with other languages is important.

Does the following patch to the PEP represent the consensus? If so,
I'll check it in, and update the py3k branch and wikipedia article to
match. I've allowed each type to define its own half-rounding behavior
so that Decimal can follow the current context, and float can, once
there's a portable way to set it (like C99's fesetround), follow the
current rounding mode (if people want that at the time).

Index: pep-3141.txt
===================================================================
--- pep-3141.txt        (revision 59739)
+++ pep-3141.txt        (working copy)
@@ -206,7 +206,10 @@
             """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.
+            returns a Real. Types may choose which direction to round half. For
+            example, float rounds half away from 0, and Decimal rounds it
+            according to the active context.
+
             """
             raise NotImplementedError

@@ -428,14 +431,15 @@
    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. There
+   is also a 2-argument version, ``__round__(self, other)``, called
+   from ``round(x, y)``, which should return a Real.

 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
-deprecation warning.)
+deprecation warning.) In 2.6, ``math.floor``, ``math.ceil``, and
+``round`` will continue to return floats.

 ``complex.__{divmod,mod,floordiv,int,float}__`` also go away. It would
 be nice to provide a nice error message to help confused porters, but


-- 
Namasté,
Jeffrey Yasskin