prePEP: Money data type

[John Roth]

"Ian Bicking" <ianb at colorstudy.com> wrote in message
news:mailman.195.1066490770.2192.python-list at python.org...
> On Friday, October 17, 2003, at 06:39 PM, John Roth wrote:
> > 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?
>
> Does the rounding policy belong to the money, or to the context in
> which the money is used?  I would expect it belongs to the context,
> which would imply the policy should be specified by method name or an
> argument to a method.

I've seen instances where one had to apply different rounding
policies to different quantities in the same program. I've also
seen quite bizzare rounding policies, mostly on actuarial calculations
where the actuary was trying to make the result match the salesperson's
desire to get the account.

My suspicion is that, if you want to handle rounding properly,
you may have to give up using the builtin operators for
some cases: they don't give you the flexibility to specify the
exact characteristics of the result of the operation. It might
be possible to do what's needed by subtyping a virtual
base class that requires plugging in a rounding policy, but
even that doesn't help when you try to mix two different
subtypes of money with two different rounding policies.

>
> > 4. Repr should round trip. That's basic
> > Python. This means that repr() should
> > return something that the money()
> > constructor understands regardless of
> > the current locale setting.
> > Making it human readable is the responsibility
> > of either str(), the % operator or a hypothetical
> > .printf() method.
>
> No, the only places where repr() round trips is for Python literals.
> If there was a literal representation for a money object, then yes use
> that, otherwise the result of repr should be programmer readable and
> helpful.

I will grant you that repr() doesn't round trip for every object type,
but there's no reason it shouldn't be able to for objects that don't
require other objects in their initializers.

>
> > 6. On operators. What happens to precision
> > on multiplication and division?
>
> My impression of accounting rules (of which I'm not highly informed) is
> that numbers are always presumed to be completely accurate, by dictate
> if not circumstance.  You settle accounts by transferring money -- you
> can't transfer ranges of money or fuzzy amounts of money.  It's better
> to be arbitrary than imprecise in this instance.

It's even better to follow the dictates of the law or the contract
exactly.

John Roth