[Python-Dev] Decimal & lt; -& gt; float comparisons in py3k.

[Glenn Linderman]

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
> there.
>    

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 
arithmetic.

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 
for them.

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.

Glenn