On Wed, Mar 17, 2010 at 12:36 AM, Raymond Hettinger <raymond.hettin...@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 useful. 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. -- Mark _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
