> > I propose adding an "abstract" money base type to the standard > > library, to be subclassed by real money/decimal implementations. > > Why do we need this? I guess that would be Question #1... > > --Guido van Rossum (home page: http://www.python.org/~guido/) I can think of 3 reasons; I've seen all these occur in real life. Reason 1: Currency safety. Having a special type can rule out subtle programming errors. Imagine this: >> x = Money(3, "USD") >> y = Money(4.5, "NLG") >> z = x + y TypeError: can't add different currencies Likewise, if you add or subtract money you get money; if you divide money in the same currency you get a float; and just about any other operation might be an error. IMHO a basic type should just rule out operations; subclasses could do clever conversions etc. (Does anyone need Euro triagulation rules in the Python standard library?) Reason 2: fixed decimals SQL databases and AS400s have fixed decimal data types and can do math on thousands or millions of numeric fields at C-like speeds. There would be a (very small) market for a type that could do this. Reason (3): speed If I went for a Python "money class" with smart behaviour, I'd get a sizable speed hit compared to floats. Let's say I want to average a time series of 1000 bond prices; it will be faster on floats than on Python classes. IMHO all these are best served by an extension package not in the core language - but having a common base for them to inherit from would get a thumbs-up from me. Best Regards, Andy Robinson
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4