Le 11/03/2014 11:51, Oscar Benjamin a écrit : >
When it comes to non-integer types there's just no single good way of doing it. So just in the stdlib we already have float, Fraction and Decimal. The additional libraries that I use have many more numeric types than that. The idea here is that for most users decimal128 just is the decimal type.
Who are those "most users"? Those who are currently happy with float?
Defining two different but similar types, one for "beginner use" and one for "expert use" is a terrible design pattern. People will have to know about both types. Some libraries will choose to return the beginner type, others will choose to return the expert type. Users will have to learn the differences, will have to learn how conversions work, etc.
The decimal.Decimal type is IMO overly complex and should really be for niche use-cases like other non-stdlib multi-precision numeric types.
What is complex about it? The notion of a decimal's precision in number of digits is understandable by a 10 year old. It is arguably much simpler than unicode and character encodings. Besides, for most applications Decimal's current precision will be good enough: changing the current context (which, I believe, is thread-local, not process-global) is only necessary in special cases.
Java's BigDecimal is more user friendly in some important ways. It performs all calculations exactly until you explicitly round.
So if call BigDecimal(2).sqrt(), I get an infinite precision BigDecimal? :-)
(or perhaps it doesn't have .sqrt()?)
C++ is introducing decimal32, decimal64, and decimal128 as fixed-width decimal floating point types as according to IEEE-754-2008.
C++ has tons of integer types too, but Python has a single one.