[Python-Dev] prePEP: Money data type
aleaxit at yahoo.com
Fri Oct 17 17:21:48 EDT 2003
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,
> 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.
More information about the Python-Dev