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.