Against PEP 240

[Roman Suzi]

On Sat, 2 Jun 2001, Clark C . Evans wrote:

>On Thu, 31 May 2001, Tim Peters wrote:
>> [Roman Suzi]
>> > Rounding and formating is a MUST in anything nrealy financial ;-)
>> > So, lets not put additional burden on the Python and
>> > just put "%11.2f" % round(var, 2) were due.
>>
>> I doubt that's going to make Clark feel better, as I can't
>> imagine a context in which that code snippet would make good sense.
>> That's the kind of thing he's doubtless suffering from:
>> well-intentioned attempts to worm around problems too
>> dimly understood.
>
>Nod. You'd be amazed what kind of "tricks" people use
>to get the "right" answer.  It works in the short term,
>but when the money is aggregated, taxes are calculated,
>and other numeric operations are carried out these
>"tiny" errors do accumulate.  One "minor" mistake in
>an accounting program and it brings into question the
>data integrety of evertyhing...
>
>Further, I've seen far enough of the the above
>"well-intensioned" attempts to use floating point
>representations for currency.   For me, this is the
>type of stuff nightmares are made of...    And I am
>not claiming the high ground here -- in my first few
>years I was as guilty as the next fella.  Python
>should not require the nasty initiation that I
>was faced with.
>
>...
>
>There are two general approaches: (a) do all of your
>calculations in "cents", or (b) use a BCD (binary
>coded decimal) library.
>
>Unfortunately the former isn't always an option...
>for two reasons, first people don't think in cents
>so it makes calculations quite a bit harder.  Second,
>for some currencies, numeric overflows are too common.
>Let's say the annual revenue of your company was
>1.5 million dollars.  This is 342,540,983,606 Lire*100.
>With this number, you just had an overflow if you
>were using long (32) bit integers (4,294,967,296)
>
>...
>
>More and more people will be using Python for financial
>applications, from accounting to purchase order processing.
>Must we require each of these programmers, who perhaps
>have business degrees, to completely "grok" all of the
>subtleties of numeric analysis before they can write
>their first invoice?    Certainly we could write and
>publish a "BCD" library...  but I question how many
>junior programmers would know what BCD is... let alone
>taking active initiative to look for BCD.
>
>I'd rather have the default be some sort of BCD
>representation... where the programmer has to "work"
>to get the innaccuracy of a floating point representation.
>I'm not too worried about speed.  If it's slow then
>the programmer will search the documentation to find
>out why.  And, after some looking will stumble across
>the "bcd vs float" distinction and then make the
>'conscious' choice to use a floating point representation
>and having to concern themselves with all of its
>idiosyncrasies.

This said, what is the right way to deal with
currencies in Python right now?


Sincerely yours, Roman Suzi
-- 
_/ Russia _/ Karelia _/ Petrozavodsk _/ rnd at onego.ru _/
_/ Saturday, June 02, 2001 _/ Powered by Linux RedHat 6.2 _/
_/ "Without my ignorance, your knowledge would be meaningless.." _/