[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
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