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
_______________________________________________
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
