prePEP: Money data type

[Pettersen, Bjorn S]

> From: Alex Martelli [mailto:aleaxit at yahoo.com] 
> 
> On Monday 20 October 2003 06:33 am, Ian Bicking wrote:
>    ...
> > > BECAUSE for reasons totally unclear to me x isn't allowed to carry
> > > the rounding spec, even though all computations on x must use that
> > > spec, would drive me away in no time.
> >
> > Money could carry the rounding policy -- I don't really know if
that's
> > right or not, I'm not convinced either way.  But I'm not sure it's
> > really "money" if it carries a rounding policy.  A rounding policy
> > isn't intrinsic to the notion of money.  EU has a rounding policy,
but
> 
> Thanks, you clarified your reasons now, even though I disagree.
[..]

> > If you include a rounding policy you are really specifying an
> > accounting entry.  That "money" cannot be put into other accounts
> > without checking and converting the rounding policy.  But the
rounding
> > policy may not be the only policy -- I don't have experience to know
of
> > other circumstances, but it's easy enough to imagine other kinds of
> > policies that belong to entries.
> 
> But class Money in itself should specify *arithmetic*, that's 
> all.
[..]

I agree that Python should stay away from accounting, which is why I
would prefer that a Money type be built on top of a fixed precision
built-in type. (It would have been nice to be able to use $24.85 as a
constant in code, however that may be influenced by my current location
<wink>).

FWIW, I'm sitting "next" to several TBs of financial data and the only
time I care about rounding, the calculations are so esoteric (and
critical :-) that it must be done by existing library code -- i.e. I
could use a fixed precision type, but a Money type would be
'overkill'...

-- bjorn