prePEP: Money data type

[Alex Martelli]

John Roth wrote:

> I've made a few edits for spelling and grammar, but I
> haven't cleaned up everything, and I haven't made
> any substantive changes to the text. Do with it what
> you will.
> 
> Substantive issues:
> 
> 1. I've seen lots of strange rounding policies in
> various nooks and crannies. Is there any way of
> specifying a rounding policy that would be used
> and inherited by the result money object?

Amen, Hallelujah.  I've followed up to Batista's similar
post to python-dev by pointing out chapter and verse of
EU regulations that _mandate_ "rounding to nearest and
always round exactly-halfway UPWARDS", for example.

As a side note, it's quite possible to spend inordinate
amounts of attention on formatting.  I would suggest that
a fundamental 'money' class should first of all nail down
the *computation* issues (just that variety of rounding 
specs is gonna be SUCH a bear...!) and receiving and
returning information.  Once that is done, one or more
formatting functions can always be developed, be it as
methods of the money class, a subclass, or whatever.  No
matter how it may look from Cobol, RPG, etc, correct and
accurate computation that respects all relevant fiddly
accounting regulations and practices IS the essence --
formatting requirements vary widely, and, if the base class
does arithmetic "right" AND allows complete receiving and
returning of information, extra formatting niceties can
always be "plugged on top" later.  But if the arithmetic
is creaky -- e.g., _VB_'s "money" type -- all the cutesy
formatting in the world won't ever fix it.


Alex