On 8/4/06, Ron Adam <[EMAIL PROTECTED]> 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
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
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 __
Greg Ewing wrote:
> Nick Coghlan wrote:
>
>> Would it be worthwhile to design a common rounding mechanism that can be
>> used
>> to cleanly round values to the built in floating point type, as well as
>> being
>> able to access the different rounding modes for decimal instances?
>
> Sounds li
Nick Coghlan wrote:
> Would it be worthwhile to design a common rounding mechanism that can be used
> to cleanly round values to the built in floating point type, as well as being
> able to access the different rounding modes for decimal instances?
Sounds like a job for a new protocol, such as
Nick Coghlan wrote:
> The implicit Decimal->float conversion
Hang on, I thought there weren't supposed to be any
implicit conversions between Decimal and float.
--
Greg
___
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/
Some musings inspired by the rounding discussion on python-dev.
The Decimal module provides all of the rounding modes from the general decimal
arithmetic specification [1].
Both Decimal rounding methods (quantize() and to_integral()) return Decimal
instances - a subsequent explicit conversion t
