[Python-3000] Rounding in Py3k
rrr at ronadam.com
Fri Aug 4 12:46:42 CEST 2006
Greg Ewing wrote:
> Ron Adam wrote:
>> I'm still not sure why "__round__" should be preferred in place of
>> "round" as a method name. There isn't an operator associated to
>> rounding so wouldn't the method name not have underscores?
> I was thinking there would be functions such as round(),
> trunc(), etc. that use __round__ to do their work. That's
> why I called it a protocol and not just a method.
I understood your point. :-)
If you look at the methods in int, long, and float, there are no methods
that do not have double underscores. While there are many that don't in
unicode and string. There also are many methods in Decimal that do not
use the double underscore naming convention.
I am just curious why not in general for the builtin numeric types.
The style guide says...
> - __double_leading_and_trailing_underscore__: "magic" objects or
> attributes that live in user-controlled namespaces. E.g. __init__,
> __import__ or __file__. Never invent such names; only use them
> as documented.
So would __round__ interact with the interpreter in some "magic" way? I
take "magic" to mean the interpreter calls the method directly at times
without having python coded instructions to do so. Such as when we
create an object from a class and __init__ gets called by the
interpreter directly. The same goes for methods like __add__ and
But that doesn't explain why int, long, and float, don't have other
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.
More information about the Python-3000