Aahz wrote: #- The first thing you should do is talk with Eric Price #- (eprice@tjhsst.edu), author of the code. You don't need to #- use SF for #- now; CVS should be fine, but you should find out whether #- Eric would like #- to approve changes first. OK, I'll mail him. #- There's no reason you can't start with a pre-PEP now; I'd focus on #- interface (i.e. the question of what ``Decimal(5)/3`` and #- ``5/Decimal(3)`` should do -- my personal take at this point is that #- both ought to fail). Well, there's wide discussion about this when I posted the pre-PEP of Money. The raisoning of majority is that when two operands are of different type, the less general must be converted to the more general one:
With this in mind, the behaviour would be:
and
but I really don't know if the first behaviour should be extended to the latter two. Anyway, I'll post the pre-PEP and we all should see, :) Thanks. . Facundo
On Mon, Oct 27, 2003, Batista, Facundo wrote:
Absolutely not. No way, no how, no time. -1000 The problem is that Decimal is capable of greater precision, accuracy, and range than float. You could reasonably argue that the result should be a Decimal, but that has problems with numbers like 1.1 that already are inexactly represented in Python. My opinion is that conversion between float and Decimal should always be explicit (and my recollection is that Tim Peters agrees).
This is acceptable (because you can't lose anything), but I'm overall leaning toward always requiring explicit conversion. The one thing I dislike in Cowlishaw's algorithms is that integers are always zero-extended. IOW, 1e3 is always 1000. But a standard is a standard; if we want Python's Decimal results to be interoperable with other languages, we have to do that. -- Aahz (aahz@pythoncraft.com) <*> http://www.pythoncraft.com/ "It is easier to optimize correct code than to correct optimized code." --Bill Harlan
On Mon, Oct 27, 2003, Batista, Facundo wrote:
Absolutely not. No way, no how, no time. -1000 The problem is that Decimal is capable of greater precision, accuracy, and range than float. You could reasonably argue that the result should be a Decimal, but that has problems with numbers like 1.1 that already are inexactly represented in Python. My opinion is that conversion between float and Decimal should always be explicit (and my recollection is that Tim Peters agrees).
This is acceptable (because you can't lose anything), but I'm overall leaning toward always requiring explicit conversion. The one thing I dislike in Cowlishaw's algorithms is that integers are always zero-extended. IOW, 1e3 is always 1000. But a standard is a standard; if we want Python's Decimal results to be interoperable with other languages, we have to do that. -- Aahz (aahz@pythoncraft.com) <*> http://www.pythoncraft.com/ "It is easier to optimize correct code than to correct optimized code." --Bill Harlan
participants (2)
-
Aahz -
Batista, Facundo