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