[Python-Dev] Decimal <-> float comparisons in py3k.

Mark Dickinson dickinsm at gmail.com
Wed Mar 17 15:19:51 CET 2010

On Wed, Mar 17, 2010 at 12:36 AM, Raymond Hettinger
<raymond.hettinger at gmail.com> wrote:
> On Mar 16, 2010, at 9:41 AM, Guido van Rossum wrote:
>> Also supporting comparisons but not other mixed operations is going to
>> be confusing. If you are sticking to that behavior I think mixed
>> comparisons should also be ruled out.
> The difference is that mixed comparisons currently do give a result,
> but one that is non-sensical.  The proposal is a make in give a
> meaningful result, not as an extra feature, but in an effort to not
> be wrong.

Yes, exactly.

A number of people (including me, early in the issue tracker
discussion) have suggested that it would be
confusing/inconsistent/strange to allow mixed-type comparisons but not
mixed-type arithmetic.  But it's not clear to me exactly why this
would be a bad thing.

It seems likely that for serious applications there's little benefit
in allowing float<->Decimal comparisons if mixed-type arithmetic isn't
allowed:  if you're checking that b > a, it's probably because you're
about to subtract b from a, or divide b by a, or do some other piece
of arithmetic that depends on that condition being true.  But for
simply playing around with numbers on the command line, and for
helping free people from their floating-point misconceptions, I think
having these float<->Decimal comparisons available is potentially

I understand the argument about not adding this feature to 2.x if it's
not going to go into 3.x;  but I'm convinced enough that the 2.x
behaviour should change that I'd prefer to add it to both 2.x and 3.x
than to neither.

The other option would be to leave 3.x alone and just add a py3k
warning to 2.x, so that at least there's some indication of where
strange results are coming from.


More information about the Python-Dev mailing list