[Tim Peters]
#- [Batista, Facundo] #- > Well, I think we must decide how it works #- > #- > With: #- > #- > >>> d = Decimal('12345.678') #- > >>> d #- > Decimal( (0, (1, 2, 3, 4, 5, 6, 7, 8), -3) ) #- > >>> str(d) #- > '12345.678' #- > #- > And being the syntax Decimal.round(n), we have the #- > following options: #- > #- > a) n is the quantity of relevant digits of the #- > final number (must be non negative). #- ... #- > b) n has the same behaviour that in the built in round(). #- ... #- > What option do you all like more? #- #- I like (c) best: drop round(), because it's redundant -- #- there are other #- ways to do (a) and (b) already. Perhaps (b) isn't obvious, #- so extending #- your example with what already exists: #- #- >>> dimes = Decimal.Decimal('0.1') #- >>> print d.quantize(dimes) #- 12345.7 #- >>> print d.quantize(Decimal.Decimal('1e1')) #- 1.235E+4 #- >>>
The round() method has the appealing that it could has the same name/meaning/function that the built in round().
But, the PEP is for implementing the Spec, so I'm +1 to drop round(), at least in this stage.
#- In general, we should be very reluctant to extend the spec #- at the start: #- it's complicated, subtle and exacting, and plenty of big #- brains are working #- hard on getting the spec exactly right. Alas, it's also #- still a bit of a #- moving target.
Agree, agree.
. Facundo
[Tim Delaney]
Perhaps the built-in round should be modified to work with Decimal ...
Eventually, it should -- and many other changes throughout Python, outside of Decimal, should also be made. That won't happen for the first release, though, and possibly never if Decimal doesn't become popular.
Examples:
+ Float format codes, like %20.6g, make fine sense for Decimal, but feeding them Decimals won't do any good.
+ A Decimal version of the math module doesn't exist.
+ Looking up context all the time is expensive, and should eventually become part of CPython's C-level thread state (much as your FPU's context register(s) are part of your C's runtime thread state).
[Batista, Facundo]
The round() method has the appealing that it could has the same name/meaning/function that the built in round().
As Tim Delaney said later, the best way to do that would be to change the implementation of Python's builtin round(). I don't think changing Python (beyond adding the new module) is in scope for the first release, though.
Tim Peters wrote:
[Batista, Facundo]
The round() method has the appealing that it could has the same name/meaning/function that the built in round().
As Tim Delaney said later, the best way to do that would be to change the implementation of Python's builtin round(). I don't think changing Python (beyond adding the new module) is in scope for the first release, though.
I think we probably want a supplemental PEP for upgrading the `math` module plus appropriate builtins (like round) to handle Decimal. A quick scan through the docs reveals
- All the `math` module (thin wrappers for float, hand-written code for Decimal I guess). - abs - divmod - pow - round
which look like candidates.
Tim Delaney
-
Batista, Facundo -
Tim Delaney -
Tim Peters