Against PEP 240

[Clark C . Evans]

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.

burned-one-too-many-time'ly yours,

Clark