[Python-3000] Rounding in Py3k

[Ron Adam]

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.
> 
> --
> Greg

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 
__repr__, etc...

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.

Cheers,
    Ron