prePEP: Money data type

[John Roth]

"Alex Martelli" <aleax at aleax.it> wrote in message
news:S9fkb.308725$R32.10140453 at news2.tin.it...
> Ian Bicking wrote:
>
> > 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.
>
> So you think y=x/2 should not work when x is an instance of Money,
> nor should y=x*z when x is an instance of Money and z is e.g. 0.5?
> That seems pretty limiting to me.
>
>
> > No, the only places where repr() round trips is for Python literals.
>
> Not true:
>
> >>> from sets import Set
> >>> a = Set('ciao')
> >>> print a
> Set(['i', 'a', 'c', 'o'])
> >>> therep = repr(a)
> >>> b = eval(therep)
> >>> print b
> Set(['i', 'a', 'c', 'o'])
> >>>
>
> repr + eval "round-trips" for many types that don't have Python
> literals, net of the issue of whether the type's name as given
> by repr includes the module name (and thus roundtrips after an
> import statement) or doesn't (and thus roundtrips after a from
> statement) -- it seems that it more often doesn't.
>
>
> > This article lays out some common requirements for money:
> >
> >    http://www.martinfowler.com/ap2/quantity.html
>
> Good reference, thanks.  In particular, it bluntly states its
> disagreement with your point 1 above:
> """
> A money object, however, can encode its own rules for rounding,
> which means that most of the time you don't have to be aware
> of the rounding rules while you are working with money.
> """
>
> Fowler's Money class includes the currency unit, just as any
> of his Quantity classes includes the unit of measure.  The
> Money class under discussion is specifically designed to NOT
> include the currency unit.  I'm not sure which design is
> more suitable here, though.

Without devoting a huge amount of thinking time to it, I'd
be tempted to go with solving the larger problem: basic
financial calculations. Sometimes what looks like a small
problem is difficult to solve because you don't have enough
context. Integer division is a great case in point: there are at
least three different ways of defining what the remainder
should be, and they are all right - in different domains.

There is, by the way, a great example of a rounding
policy that I bet you don't want to program: how do you
round the tip when you go out to eat?

John Roth

>
> Alex
>