[Python-3000] Rounding in Py3k

Guido van Rossum guido at python.org
Thu Aug 10 20:40:46 CEST 2006


On 8/4/06, Ron Adam <rrr at ronadam.com> wrote:
> But that doesn't explain why int, long, and float, don't have other
> non-magic methods.
>
> I'm not attempting taking sides for or against either way, I just want
> to understand the reasons as it seems like by knowing that, the correct
> way to do it would be clear, instead of trying to wag the dog by the
> tail if you know what I mean.

I'm probably the source of this convention. For numbers, I find foo(x)
more readable than x.foo(), mostly because of the longstanding
tradition in mathematics to write things like f(x) and sin(x).

Originally I had extended the same convention to strings; but over
time it became clear that there was a common set of operations on
strings that were so fundamental that having to import a module to use
them was a mistake, and there were too many to make them all
built-ins. (I didn't insist on not using methods/attributes for
complex, since I was already used to seeing z.re and z.im in
Algol-68).

I'm not convinced that there are enough common operations on the
standard numbers to change my mind now. I'd rather see the built-in
round() use a new protocol __round__() than switching to a round()
method on various numbers; this should hopefully make it possible to
use round() on Decimal instances.

A question is what the API for __round__() should be. It seems Decimal
uses a different API than round(). Can someone think about this more
and propose a unified and backwards compatible solution?

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)


More information about the Python-3000 mailing list