prePEP: Money data type

[Alex Martelli]

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.


Alex