[Python-ideas] Python Numbers as Human Concept Decimal System

Antoine Pitrou solipsis at pitrou.net
Tue Mar 11 14:30:03 CET 2014


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.

Regards

Antoine.




More information about the Python-ideas mailing list