Mark Dickinson <[email protected]> added the comment:
Float-to-decimal comparisons have been fixed, and the Decimal hash function
changed so that numerically equal Decimal and float instances hash equal, in
r79583.
The idea of raising an exception for float<->Decimal comparisons was discarded
partly for backwards compatibility reasons, and partly because having __eq__
raise an exception causes difficulties for sets and dicts: for example, if
equality checks between floats and Decimals raised an exception then '{-1.0,
Decimal(-3)}' would give a valid set (the two values have different hashes, so
the Decimal.__eq__ method is never invoked), but '{-1.0, Decimal(-2)}' would
raise an exception (because the two set elements have equal hashes, so
Decimal.__eq__ is invoked in order to determine whether the two elements are
equal or not).
(General principle: if x and y are hashable, x == y should never raise an
exception.)
This is still only a partial fix: comparisons between Decimal and Fraction
instances still behave oddly. This seems less likely to cause problems in
real-life code, though. The changes needed to make Decimal <-> Fraction
comparisons correct are too intrusive and not yet well tested enough to make it
into 2.7. (See issue 8188).
As discussed on python-dev, I'll forward port this to py3k; with any luck,
py3k will also grow valid comparisons for Decimal <-> Fraction.
----------
versions: -Python 2.7
_______________________________________
Python tracker <[email protected]>
<http://bugs.python.org/issue2531>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
