[Python-Dev] Decimal <-> float comparisons in py3k. (original) (raw)
Raymond Hettinger raymond.hettinger at gmail.com
Thu Mar 18 18:55:41 CET 2010
- Previous message: [Python-Dev] Decimal <-> float comparisons in py3k.
- Next message: [Python-Dev] Decimal <-> float comparisons in py3k.
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On Mar 18, 2010, at 5:23 AM, Steven D'Aprano wrote:
On Thu, 18 Mar 2010 08:58:25 am Raymond Hettinger wrote:
On Mar 17, 2010, at 1:59 PM, Steven D'Aprano wrote:
On Thu, 18 Mar 2010 07:44:21 am Raymond Hettinger wrote:
The spectrum of options from worst to best is 1) compare but give the wrong answer 2) compare but give the right answer 3) refuse to compare.
Why is 3 the best? If there is a right answer to give, surely giving the right answer it is better than not? From the early days of the decimal module, we've thought that mixed float-decimal operations are 1) a bit perilous and 2) have few, if any good use cases. When it comes to arithmetic operations, I agree. Is there anyone on python-dev willing to argue the case for allowing implicit mixed float/Decimal arithmetic operations? The arguments in the PEP seem pretty convincing to me, and I'm not suggesting we change that. But comparison operations are different. For starters, you don't need to worry about whether to return a float or a Decimal, because you always get a bool. In theory, both Decimals and floats are representations of the same underlying thing, namely real numbers, and it seems strange to me that I can't ask whether two such real numbers are equal just because their storage implementation is different. I can see three reasonable reasons for avoiding mixed comparisons: (1) To avoid confusing float-naive users (but they're confused by pure float comparisons too). (2) To avoid mixed arithmetic operations (but comparisons aren't arithmetic). (3) If Decimals and floats compare equal, they must hash equal, and currently they don't (but Mark Dickinson thinks he has a solution for that).
Thanks for the thoughtful post.
The question is which behavior is most useful, most of the time. If a person truly wants to do mixed comparisons, it's trivially easy to do so in a way that is explicit:
somedecimal < Decimal.from_float(somefloat)
My thought is that intentional mixed compares of float and decimal are very rare relative to unintentional cases. IOW, most of the time that x<y makes a float/decimal comparison, it is actually an error (or the user simply doesn't understand what his or her code is actually doing). That user is best served by refusing the temptation to guess that they really wanted to go down this path.
The zen of this particular problem:
explicit is already easy
implicit is likely to let errors pass silently
therefore, explicit is better than implicit
the special and rare case of really wanting a float/decimal comparison is rare enough that it isn't worth making the operation implicit, especially when the explicit option is so easy.
Do you want protection from probable errors or do you have compelling use cases for implicit conversion behavior where an explicit conversion would have been too much of a burden?
Raymond
- Previous message: [Python-Dev] Decimal <-> float comparisons in py3k.
- Next message: [Python-Dev] Decimal <-> float comparisons in py3k.
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]