[Python-Dev] Adventures with Decimal

[Tim Peters]

[Michael Chermside]
> Tim, I find Raymond's arguments to be much more persuasive.
> (And that's even BEFORE I read his 11-point missive.) I
> understood the concept that *operations* are context-
> dependent, but decimal *objects* are not, and thus it made
> sense to me that *constructors* were not context-dependent.
>
> On the other hand, I am NOT a floating-point expert. Can you
> educate me some?

Sorry, I can't make more time for this now.  The short course is that
a module purporting to implement an external standard should not
deviate from that standard without very good reasons, and should make
an effort to "hide" whatever deviations it thinks it needs to indulge
(e.g., make them harder to spell).  This standard provides 100%
portable (across HW, across OSes, across programming languages)
decimal arithmetic, but of course that's only across
standard-conforming implementations.

That the decimal constructor here deviates from the standard appears
to be just an historical accident (despite Raymond's current
indefatigable rationalizations <wink>).  Other important
implementations of the standard didn't make this mistake; for example,
Java's BigDecimal|(java.lang.String) constructor follows the rules
here:

    http://www2.hursley.ibm.com/decimalj/deccons.html

Does it really need to be argued interminably that deviating from a
standard is a Big Deal?  Users pay for that eventually, not
implementors.  Even if a standard "is wrong" (and leaving aside that I
believe this standard asks for the right behavior here), users benefit
from cross-implementation predictability a lot more than they can
benefit from a specific implementation's non-standard idiosyncracies.