<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div>On Jun 4, 2015, at 08:21, David Mertz <<a href="mailto:mertz@gnosis.cx">mertz@gnosis.cx</a>> wrote:</div><blockquote type="cite"><div><p dir="ltr">
On Jun 4, 2015 8:12 AM, "Steven D'Aprano" <<a href="mailto:steve@pearwood.info">steve@pearwood.info</a>> wrote:<br>
> The decimal module is not free to do whatever we want. It can only do<br>
> what is specified by those standards.</p>
<p dir="ltr">That's not quite true. The class decimal.Decimal must obey those standards. We could easily add decimal32/64/128 types to the module for those different objects (and I think we probably should).</p></div></blockquote><div>If we add decimal32/64/128 types, presumably they'd act like the types of the same names as specified in the same standards. Otherwise, that would be very surprising.</div><div><br></div><div>Also, I'm not entirely sure we want to add those types to decimal in the stdlib. It would be a lot less work to implement them in terms of an existing C implementation (maybe using the native types if the exist, Intel's library if they don't). But I don't think that's necessarily desirable for the stdlib. Is this a big enough win to justify CPython being written in C11 instead of C90 (or, worse, sometimes one and sometimes the other, or a combination of the two), or to add a dependency on a library that isn't preinstalled on most systems and takes longer to build than all of current CPython 3.4? For a PyPI library, none of those things matter (in fact, a PyPI library could use C++ on platforms where the native types from the C++ TR exist but the C ones don't, or use Cython or CFFI or Boost::Python instead of native code, etc.),  and the stdlib's decimal docs could just point to that PyPI library.</div><blockquote type="cite"><div><p dir="ltr">For that matter, it wouldn't violate the standards to add decimal.PythonDecimal with some other behaviors. But I can't really think of any desirable behaviors that are mathematically possible to put there.</p></div></blockquote><div>I think it would still make sense to put it somewhere else. A module that declares that its behavior corresponds to a standard that adds a little bit of standard-irrelevant behavior is fine. For example, a conversion from Fraction to Decimal that worked "in the spirit of the standards" and documented that it wasn't specified by either standard. But adding a whole new class as complex as Decimal means half the module is now standard-irrelevant, which seems a lot more potentially confusing to me.</div><blockquote type="cite"><div><p dir="ltr"> There isn't going to be a decimal.NeverSurprisingDecimal class in there.</p></div></blockquote>Start with your favorite axioms for the integers and your favorite construction of the reals, then negate the successor axiom. Now you have a fully-consistent, never-surprising, easily-implementable real number type that follows all the usual mathematical laws over its entire set of values, {0}. :)<div><br></div></body></html>