On Mar 20, 2010, at 4:27 PM, Jeffrey Yasskin wrote: > > When designing it, I tried to include a notion of exact/inexact types, > but we couldn't find anything practical to do with them, so we took > them out.
The were also other reasons that they were taken out. The notion of inexactness is a taint, not a property of a type. The design documents for the decimal spec aimed for the ability to do either inexact or exact calculations (and to encompass integer and fixed-point arithmetic). That is in-part why decimal is suitable for accounting work. A person can forbid any inexactness by setting a context flag that would raise an exception if any inexact calculation occurs. Another design principle for decimal is the notion that numbers are always exact, it is the results of operations that are subject to rounding. That is why the decimal constructor is not context sensitive. So, as Jeffrey says, the notion of exactness and inexactness is not built in to the numeric tower. Instead, it is about which operations or methods can be expected to apply to a given type (i.e. both float and Decimal support the necessary methods to register as a Real). In terms of interoperability of concrete types, we're in the fortunate position that any float can be exactly converted to a Decimal and any Decimal can be exactly converted to a Fraction. Raymond _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
