[Python-Dev] prePEP: Money data type

[Alex Martelli]

On Friday 17 October 2003 10:49 pm, Batista, Facundo wrote:
   ...
> The idea is to make a Money data type, basically for financial uses, where
> decimals are needed but floating point is too inexact.  The Money data type

Good, but the name seems ambiguous -- I would expect 'money' to include
a *currency unit*, while these are just numbers.  E.g., these days for me a
"money amount" of "1000" isn't immediately significant -- does it mean "old
liras", Euros, SEK, ...?  If a clearer name (perhaps Decimal?) was adopted,
the type's purposes would be also clearer, perhaps.

> 6. About repr(). Should ``myMoney == eval(repr(myMoney))``?

I don't see why not.

> 3. Not to support strings with engineer notation (you don't need this when
>    using money).

Actually, with certain very depreciated currencies exponent notation would
be VERY handy to have.  E.g., given than a Euro is worth 1670000 Turkish
Liras today, you have to count zeros accurately when expressing any
substantial amount in Turkish Liras -- exponential notation would help.

> 10. To support the built-in methods:

I think you mean functions, not methods, in Python terminology.

>         - min, max
>         - float, int, long (int and long are rounded by Money)

Rounding rather than truncation seems strange to me here.

>         - str, repr
>         - hash
>         - copy, deepcopy
>         - bool (0 is false, otherwise true)
>
> 11. To have methods that return its components. The value of Money will be
>     ``(int part) + (frac part) / (10 ** precision)``.
>
>         - ``getPrecision()``: the precision
>         - ``getFracPart()``: the fractional part (as long)
>         - ``getIntPart()``: the int part (as long)

Given we're talking about Python and not Java, I would suggest read-only
accessors (like e.g. the complex type has) rather than accessor methods.
E.g., x.precision , x.fraction and x.integer rather than x.getPrecision() etc.


> 12. The rounding to be financial. This means that to round a number in a
>     position, if the digit at the right of that position is bigger than 5,
>     the digit at the left of that position is incremented by one, if it's
>     smaller than 5 isn't::
>
>         1.123 --> 1.12
>         1.128 --> 1.13
>
>     But when the digit at the right of that position is ==5. There, if the
>     digit at the left of that position is odd, it gets incremented,
> otherwise
>     isn't::
>
>         1.125 --> 1.12
>         1.135 --> 1.14

I don't think these are the rules in the European Union (they're popular
in statistics, but, I suspect, not legally correct in accounting).  I can try
to research that, if you need me to.


Alex