However, unlike RPG, we should probably ensure that attempts to overflow or underflow the scale result in NaN or Overflow conditions, rather than assuming the user is right and losing the significant digits. Since this would be based on infinite-precision numbers, I don't think that this would be an issue.
Three very general observations before I disappear for Christmas:
(1) I think there is great mileage in combining the fixed-decimal concept with Martin Fowler's Quantity pattern, so that a variable could be defined as not just two decimal places but also (say) "GBP" or "USD", and it would be an error to add the two. Same applies for adding metres, kilograms and other quantities. There has also been discussion that the 'type' of a quantity should determine what math should apply.
(2) If Python is going to be used increasingly in eCommerce, it should be good at dealing with money - maybe not in the core language, but we should aim for one standard package.
(3) We have a python-finance list (email@example.com), recently generalized to cover business systems, which is a good place to discuss this if anyone wants to. There are people there who have time, would love to prototype something (indeed some work started in this area 3 months back), and would use it at work too. This would be an ideal first target for that group - or indeed for a finance-sig. I'll pursue this in the New Year.
===== Andy Robinson
My opinions are the official policy of Robinson Analytics Ltd. They just vary from day to day.
Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com