[Python-Dev] Decimal & lt; -& gt; float comparisons in py3k.
v+python at g.nevcal.com
Fri Mar 19 19:42:39 CET 2010
On 3/19/2010 4:50 AM, Antoine Pitrou wrote:
> Glenn Linderman<glenn<at> nevcal.com> writes:
>> On the other hand, if the default behavior is to do an implicit
>> conversion, I don't know of any way that that could be turned into an
>> exception for those coders that don't want or don't like the particular
>> type of implicit conversion chosen.
> You still haven't given a good reason why we should raise an exception rather
> than do a comparison, though.
> The fact that some particular coders don't like "the particular type of implicit
> conversion chosen" is a particularly weak argument. Python isn't a language
> construction framework; we try to choose useful defaults rather than simply give
> out a box of tools. If some people don't like the defaults (significant
> indentation, limitless precision integers, etc.), there are other choices out
The whole point of providing Decimal is for applications for which float
is inappropriate. I didn't think I needed to reproduce PEP 327 in my email.
So when a coder choose to use Decimal, it is because float is
inappropriate. Because float is inappropriate, mixing Decimal and float
is inappropriate. Having the language coerce implicitly, is
inappropriate. All this is in the PEP. Note that the PEP actually says
that the problem is not doing implicit arithmetic (as some have reported
in this thread) but in doing implicit coercions. In order to do
implicit comparisons, one must do an implicit coercion. Hence the PEP
actually already prohibits implicit comparisons, as well as implicit
Now the proposal is to start down the slippery slope by allowing
comparisons. To start with, neither decimal nor float comparisons, are,
in general, exact. (Although it is more common for decimal calculations
to contain the code to do rounding and significant digit calculations
than float code, due to its use in monetary calculations. People that
don't care about the precision tend to just use float, and no
significant digit concerns are coded.) Comparisons need to be done with
full knowledge of the precision of the numbers. The additional
information necessary to do so cannot be encoded in a binary operator.
People that do care about precision would rather not have imprecise data
introduced by accidentally forgetting to include a coercion constructor,
and have it implicitly converted; hence, the exception is much better
My original message pointed out that providing an exception solves the
problem for people that care about precision, and doesn't hinder a
solution (only a convenience) for people that somehow bothered to use
Decimal but then suddenly lost interest in doing correct math. For
those people, the class I proposed can workaround the existence of the
exception, so the language can better serve both types of people, those
that care, and those that don't.
My personal opinion is that real applications that use Decimal are much
more likely to care, and much more likely to appreciate the exception,
whereas applications that don't care, aren't likely to use Decimal in
the first place, and so won't encounter the problem anyway. And if they
do, for some reason, hop on the Decimal bandwagon, then it seems to be a
simple matter to implement a class with implicit conversions using
whatever parameters they choose to implement, for their sloppy endeavors.
Yes, if implicit coercions for comparisons exist, it is possible to
write code that avoids using them... but much friendlier for people that
wish to avoid them, if the exception remains in place, unless explicitly
sidestepped through coding another class.
Implementing an exception for Decimal/float comparison attempts, rather
than comparing their types, is a giant step forward. Implementing an
implicit coercion for Decimal/float comparisons is a step down a
slippery slope, to reduce the benefits of Decimal for its users.
More information about the Python-Dev